Hi team.
The question on the GetTogether in Gent about caching database generated pages made me thinking, digging the source and the mailing list archive.
This way I found the eventcache block by Geoff, which does most of this already. To be precise, it invalidates the cache entries based on received events, it does not, however, receive those events from external sources. The sample illustrates this using an action. This action could be triggered from the outside using a simple HTTP GET.
Woohoo! "If you build it they will come..." I was beginning to despair that I was the only one who found this even remotely useful (ok, there are a few others).
The more useful way of course would be to do this through JMS. The docs already suggest this.
Yes, that is my favorite paradigm for caching database-driven stuff. I've had for some time the beginnings of a JMS block on my hdd. I can't remember the state of it. IIRC I have it connecting to a remote/local JMS server depending on config and capable of basic receiving of events. I don't think I ever worked in durable subscriptions which would be a must.
Now, I took some time to build upon what's already there and created an additional example that provides triggers for HSQLDB for automatic invalidation, either through HTTP or through JMS. Since most (all?) commercial DBMSs support Java stored procedures or functions (well, any language would do for the HTTP method), it should be simple to extend this to other DBMSs.
Ok, I'll need to look at this. I didn't think most DBMSs supported Java stored procs. I've just started working on this in Oracle 9i. Did this some time ago with 8i but things have changed slightly. I had no idea HSQL supported it - is that what you're saying? I haven't followed real recently but MySql is working on stored procs but I don't think Java is in the cards there. Still, a simple wrapper would probably work fine.
I must admit, I'm impressed with the eventcache :-)
Aw, shucks. I'm a proud papa.
In order to make the eventcache block not depend on the HSQLDB block just for the samples I added the org.hsqldb.Trigger interface as mock class to the event block.
Makes sense.
However, to compile the updated block, certain java.naming and
java.jms classes need to be present. Available from sun or obtainable
together with a complete JMS implementation from http://OpenJMS.sf.net IIUC the jms and jndi jars are redistributable. We could add them to
our CVS (?)
I didn't think they were redistributable but have no real idea. I'd love to not have the block depend on JMS since it's not strictly needed. Could we have a JMS block (as I mentioned above) which then has some eventcache-specific code?
Another nice feature would be to make the SQLTransformer cachable with
the same technique.
Unico came up with a solution for this that I like. It's not documented and no sample yet, but see the EventCacheGenerator in the block. IIRC it's a pretty classic Decorator that just adds/replaces the caching behavior of any Generator and delegates all other functions to it without recoding it. To do the same for transformations wouldn't be a big deal. (or was that what you were already referring to?)
For this it would be great if the eventcache block could be moved into core, at least the EventAware interface.
I'd be fine with this and even at one point thought of proposing it. Two reasons I didn't: 1) at the time it would have meant adding its processing to every pipeline. Since then Carsten made Cache configurable in the pipelines. This makes it more realistic to just add this to the core. It may be possible to encapsulate the event aware stuff a little better that way instead of using pure inheritance as it does now. 2) General apathy about this idea among other commiters.
Oppinions, suggestions?
I haven't put the example into our CVS, yet. It can be found at
http://www.dvs1.informatik.tu-darmstadt.de/staff/haul/misc/eventcache.tar.gz
I'll check it out soon. Unfortunately I'm working on installing doors to keep my daughter out of my office. http://images.myaeros.com/matt/5.jpg
Remove the eventcache block before and replace it with the above tar.gz (although the original classes were not modified, only the original sample was moved into a subdirectory).
At least
<file> <title>JMS</title> <description></description> <used-by>eventcache</used-by> <lib>eventcache/lib/jms-1.0.2a.jar</lib> <homepage>http://java.sun.com/jms</homepage> </file>
needs to be added to lib/jars.xml (as jdk1.4 contains jndi) and the jar added to src/blocks/eventcache/lib
To run the JMS part of the sample, get OpenJMS from http://OpenJMS.sf.net put the client jars into WEB-INF/lib and start the JMS server. The sample is configured to run with the OpenJMS demo setup using localhost and "topic1"
I'll package up the jms block I had going if that sounds worthwhile.
Geoff
