Mainframe, MVS and zOS Discussion

Hi,

Assume you are tasked with developing a web application that displays currency exchange rates for a bank's website. The exchange rates are stored on an IBM Mainframe and are accessible via web services. Currently, every time a user accesses the rates page, a request is sent to the mainframe, creating excessive load.

Most of the time, the rates retrieved are unchanged. However, rates can fluctuate during the day, and the webpage must always reflect the most up-to-date values if they have changed.The rates table on the mainframe supports triggers, allowing any update to the rates table to invoke a trigger that can call a web service. How would you design a caching architecture to reduce mainframe load while ensuring cached values are invalidated promptly on rate changes? 

Hello.

I'm going to explain a model that I've seen used before which works using DB2 and MQ, so I will assume that the exchange rate data is being held in DB2.

Rather than caching the information, what you do is clone it.

Create a copy of your exchange rate table on the web server side of things and adjust your web application to access that table instead of going to the mainframe for the information. You then set up a trigger on the master DB2 table. The trigger will activate whenever there is an update to the master table and it will be coded to send a copy of the updated row to a specific MQ queue. The server with your cloned exchange rate table will have a task that is sitting listening to that MQ queue and will update the cloned table whenever it receives a message containing new data.

Assuming the number of updates is low, this would significantly reduce your performance issues. If, however, you have multiple web servers trying to access a single clone table then you may have just moved the bottleneck. In that situation, using MQ's subscriber model and having multiple clones would be an option for relieving it.

This model does work quite well in practice, although you can get situations where an update hasn't gone through for some reason. The instance where I've seen this set up had quite a large set of tables/data that it was maintaining and we did find this happening every once in a while (an arbltary update to the rows affected usually fixed the problem). Given that exchange rate data would be a relatively smaller data set, periodically doing a complete refresh of the table by sending all of it's contents might be a good idea.
 

Thank you. Let me spend some time on this and I'll come back to you.