cache inspiration: prevaylor, persistent object cache/store
sanne Dec 16, 2002 5:24 AMJeez, Jive is getting on my nerves.
This is the third time I've posted this answer,
but haven't seen it appear anywhere yet.
Sorry for the repost
S.
-----------------------------------------------------------
Hi Bela,
Since I don't know that much about caching, shut me up if I'm talking nonsense.
To me a cache is a big map with objects in it, i.e. a collection. This is what prevayler is: no sql or such a thing.
So what does prevayler add? Well if I have a collection, and the power goes PANG!, I can restart the system and the store is restored (... no more writes lost in cache state).
Since prevayler extends to my knowledge the collection API's, the Jakarta JXPATH implementation can be applied on top of the system, it doesn't have to be. What does this add?
Say I have a map called global cache, with in it sub maps with caches for every deployed war in the system/network, with submaps for caches for say SFSB and CMPEJB, then I could retrieve cache value objects using JXPATH by:
Object cached_Object = context.getValue("globalcache/my_web_app/sfsb/cache_specific_wrapper_object[cacheObjectPKfield="id"]/cached_object");
The context object is set to point to my global collections object. The cache_specific_wrapper_object could contain time of cacheing, timeout rules, etc. The lookup is done using introspection, so things could use speeding up, but you have to admit: this is spiffy.
The point is that all the commands that modify the global collection object are submitted using a command pattern, which are spooled to disk, combined with a scheduled dump of the in memory collection th clear this command spool.
These command objects could also contain a XPath expression as above to select the objects on which to act:
1. //SFSB -> gimme all sfsb's (where // is short for /?????/?????/?????? etc)
2. //my_deployed_war -> shut this one down
2. / -> delete everything
Further more, here is an interesting quote from the site about obtaining consistent cache snapshots:
...
How can you expect to produce a consistent snapshot of a system that is constantly being modified?
This is the fundamental problem with Ambitious Transparent Persistence projects. With prevalence, the problem is solved simply by using the command log.
The command log enables the system to have a replica of the business logic on another virtual machine. All commands applied to the "hot" system are also read by the replica and applied in the exact same order. At backup time, the replica stops reading the commands and its snapshot is safely taken. Then, the replica resumes reading the command queue and gets back in sync with the "hot" system.
...
This command log could for instance be distributed using Javagroups. There would be (MBean) command routers to decide the topology of the distributed caches (which cache replicates which?), and the (MBean) cache themselves feading on these routers. As long as caches are read this could occur concurrent, the writing commands would have to pass a router.
The best thing is that since all commands are fed into the system using an object queue, the transaction characteristics are very favorable: no concurrency problems.
To avoid confusion: I'm neither a cache expert, nor a prevaylor user/expert. But if you might be interested using this technique, or maybe another one that's appealing, let me know (sanne@newfoundland.nl).
But since I've learned some XML, and don't like RDBMS that much, this setup really appeals to me.
Regards,
Sanne