-
1. ps: cache inspiration: prevaylor, persistent object cache/st
sanne Dec 13, 2002 9:17 AM (in response to sanne)P.S. the fun part is that
Jakarta Commons' Collections/ Xpath (http://jakarta.apache.org/commons/collections.html)
Can be plugged in, this provides an Xpath query interface to the store. In this way you can query objects in collections, sub-collections, sub-sub-collections etc in a transparant way. It would make it possible in a trivial to plug-in cache policies for different collections in the store.
Mmmm I must be overlooking alot,
anyway, my 2cts,
Sanne -
2. Re: cache inspiration: prevaylor, persistent object cache/st
belaban Dec 13, 2002 9:36 PM (in response to sanne)I feel less alone already ... :-)
Thanks for the hint ! Looks like Prevaylor is essentially an in-memory DB, much like HSQLDB.
I guess our caching policy will determine if, and if yes, when to persist cache entries. Some policies might be snapshotting, write-through etc. Haven't gotten to that point yet.
Bela -
3. Re: cache inspiration: prevaylor, persistent object cache/st
sanne Dec 16, 2002 5:19 AM (in response to sanne)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 in 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 -
4. Re: cache inspiration: prevaylor, persistent object cache/st
sanne Dec 16, 2002 5:21 AM (in response to sanne)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 -
5. Re: cache inspiration: prevaylor, persistent object cache/st
belaban Dec 16, 2002 8:31 PM (in response to sanne)
> 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).
So the cache itself is persistent ? I thought the whole point about having caches was that we did not persist anything, therefore not slowing down the app. These guys must put the update onto a work queue and then have a thread to write the cached entry to storage.
> 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
Sounds cool. But I think we should focus on basic functionality first. KISS, KISS, KISS. Let's not overengineer this baby. Some people think that even JCS is too big (in terms of functionality)...
> 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 is certainly nice. I assume they provide FIFO order of commands. In our implementation (That's the part I'm currently focusing on), I want to go further and provide transactional semantics for cache updates: any item is updated in all caches, or in none. This is one of the properties, the others being simple async update and sync update without locking. Maybe the Prevayler stuff can be used on top of our cache ?...
Bela