cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: caching database generated pages / eventcache block to core?
Date Mon, 13 Oct 2003 17:31:18 GMT
Christian Haul wrote:

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

I'll check it out soon.  Unfortunately I'm working on installing doors 
to keep my daughter out of my office.

> 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></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
> 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.


View raw message