[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: caching database generated pages / eventcache block to core?
From:       Christian Haul <haul () dvs1 ! informatik ! tu-darmstadt ! de>
Date:       2003-10-14 16:52:38
[Download RAW message or body]

On 13.Oct.2003 -- 03:02 PM, Geoff Howard wrote:
> Christian Haul wrote:

> I saw the following for a start:
> - Config(s) for the various connections to establish and maintain.
> - Durable subscription handling.

I think we need "at least once" semantics to avoid delivering dirty
caches. I've seen durable connections mentioned in conjunction with
subscribers that are offline. Cocoon shutting down would invalidate
caches anyway (and other program state), so is this really needed?

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

OK, I've put the sample in a new JMS block and created an action that
could send JMS messages. There's a JMSConnection (bad name) that holds
connection properties and instantiates a connection + session.

I haven't put the jars into the CVS because I would like to hear more
opinions about redistribution of jms and jndi jars. BTW OpenJMS does
distribute them.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
[prev in list] [next in list] [prev in thread] [next in thread]