cocoon-dev mailing list archives

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

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

Yes, durable subscriptions would be nice. I've been too lazy to set up 
OpenJMS to do it though :-P But I think it's not very difficult.

I guess, a JMS block would basically consist of a component that 
receives events like JMSEventListener contained in the tar.gz? What else 
would be nice to have, an action / a component sending notifications?

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

I believe the big commercial DBMSs support "java in the database". Well, 
I guess MS SQL doesn't ;-D Oracle, Sybase, DB2, and INFORMIX do. Anyway, 
all should support extensions in some language like C, C++, VBScript 
(shudder). Open source DBMS written in Java (like HSQLDB, McKoi) are 
fine, those written in another language should be at least extendable as 
long as they support triggers. (Can't reach ATM)

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

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

If you go to and select to 
download API docs & JARS, you will be presented a licence page. Scroll 
down to the middle:



2. License to Distribute Software.  In addition to the license granted 
in Section 1 (Software Internal Use and Development License Grant) of 
these Supplemental Terms, subject to the terms and conditions of this 
Agreement, including but not limited to Section 3 (Java Technology 
Restrictions), Sun grants you a non-exclusive, non-transferable, limited 
license to reproduce and distribute the Software in binary form only, 
provided that you [...]

IANAL so I have no clue if we are fulfulling the provisions.

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

I was thinking along those lines but have discarded that because I'm 
afraid that really a proxy is needed that would need to expose the very 
same interfaces as the proxied component, like setup & friends.
Haven't investigated which interfaces would need to be considered, though.

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


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


> I'll package up the jms block I had going if that sounds worthwhile.



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