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 19:02:08 GMT
Christian Haul wrote:

> Geoff Howard wrote:
>> Christian Haul wrote:
>>> 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.

No, not real difficult.  What may be difficult is setting up the 
cocoon-side to reinstate the connection in a vendor independant way.  I 
know jms is supposed to be the vendor-neutral api but I thought I was 
finding that specifics on durable subscriptions varied.  Hopefully I'm 

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

I saw the following for a start:
- Config(s) for the various connections to establish and maintain.
- Durable subscription handling.
- Configurable message listeners for each connection/topic/queue. In the 
case of EventAwareCache, this may be slightly dependent on 
implementation.  A more advanced system might want to push the new 
content out in the body of the message.  A simple one would just handle 
the lookup of the Cache and translating the Message to an Event.

Most of my thinking of the JMS block is clouded by its use in eventcache 
but of course other uses abound and a general set of services 
simplifying the integration of JMS into Cocoon would probably be 
generally useful.

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

I'd be interested to hear what's possible with postgres.

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

Anyone know if this is right for the jms and jndi packages?

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

Don't know if that would preclude that route, but I'm fine either way.

>>> 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 
> Great!
>> I'll check it out soon.  Unfortunately I'm working on installing doors 
>> to keep my daughter out of my office.  
> Sweet!
>> I'll package up the jms block I had going if that sounds worthwhile.
> Absolutely.

Ok, will do.


View raw message