This is a common pattern that I've seen many times that is similar to MessagingToUpdateDistributedCaches.

''Context:''  Let's say you need to build a front-end (a client-server or web system) on a relatively slow back-end system (for instance a mainframe CICS program).  Since there may be some mapping that needs to happen between the way that the back-end sends results and the way that they are presented to the user, and to reduce the number of trips to the back-end for redudant information, you decide to implement a mid-tier cache (a database) to hold the mapped information.  This would allow you (for instance) to display multiple web pages that represent the results of a single back-end request.

http://members.aol.com/_ht_a/kgb1001001/update.gif

Reading is easy in this situation.  You just look in the cache first and then if it's not there, query the back-end system.  You then write the result from the back-end into the cache and return the result.  Later requests from the browser for the same information retrieve it from the cache.  However writing is a little more challenging...

''Problem:''  When you receive an update from the Browser it needs to be written to both the back-end system AND the cache.  You also would probably like some transactional semantics to guarantee that the cache is not updated unless you can be reasonably assured that the back-end is also updated. So,

''Solution:''  Many developers choose to use a messaging system that can be transactionally tied together with a database (often through the X/Open XA protocol) so that you can perform both a write to the cache database and a PUT onto a queue that holds updates for the back-end system in a single transaction.  That way you have a reasonably short transaction (it is usually much faster to simply guarantee that a PUT has succeeded than to wait until confirmation that the update has happened on the back-end) so database contention on the shared cache is less than an issue.  You can rely on the guaranteed delivery semantics of the messaging system to be reasonably assured that the update will be done (or at least that every effort will be made to perform the back-end update).  

''Known uses:''  WebSphere can act as a transaction manager to transactionally tie together both MQ Series and an XA-compliant database (Oracle, DB2, Sybase, etc.) in this way. I've seen several systems built to take advantage of this. I've also seen MQ Series used as a transaction manager and a resource manager as well, since it is capable of doing both.

--KyleBrown  (comments welcome, especially other known uses and examples)