cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject caching database generated pages / eventcache block to core?
Date Mon, 13 Oct 2003 16:02:17 GMT
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.

The more useful way of course would be to do this through JMS. The
docs already suggest this.

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.

I must admit, I'm impressed with the eventcache :-)

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.

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 
IIUC the jms and jndi jars are redistributable. We could add them to
our CVS (?)

Another nice feature would be to make the SQLTransformer cachable with
the same technique. For this it would be great if the eventcache block
could be moved into core, at least the EventAware interface.

Oppinions, suggestions?

I haven't put the example into our CVS, yet. It can be found at

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 


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 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"


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message