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 Tue, 14 Oct 2003 21:36:35 GMT
Christian Haul wrote:
> Geoff Howard wrote:
>> Christian Haul wrote:
>>> On 13.Oct.2003 -- 03:02 PM, Geoff Howard wrote:
>>>> - 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?
>> Cocoon persists caches if configured to use persistent store (and if 
>> jetty is not used at least as configured in the bundled version).  So 
>> between that and network loss and reconnection, I've always thought 
>> durable subscriptions would turn out to be crucial.
> Oh yes! I tend to forget these things :-| Sure, this requires persistent 
> delivery.
>> Generally, I've thought the eventcache needs to be "fail fast" in the 
>> sense that if it encounters a condition that reveals that any events 
>> may have been missed the entire cache (or at least anything with Event 
>> based validity) needs to be invalidated.
> Right.
> About your idead of sending content with the messages -- at least if we 
> are talking about caches it is probably too difficult to use this data 
> to update the cache. But maybe we could re-request the same request that 
> filled the cache before? Or is that hashed into the cache key and can't 
> be reconstructed? OTOH doing that pro-actively could cause additional 
> load at high times... Not sure about this.

I think your scenario is right (that it would be difficult or impossible 
to re-fill the cache from an event data) but in discussion before on 
this others have always expressed this as a desire and I haven't thought 
carefully enough whether it would really be all that bad.  Still, the 
point remains that different people will have different needs for 
interpreting the received Message (perhaps some back-end system already 
has some default message subclass that they'd rather not change) and it 
seems that encapsulating that process is a smart move.

>>> 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.
>> Ok, I'll check this out.  When I went back to look at the JMS block on 
>> my HDD it was much thinner than I remembered it.  I'm sure I'll be 
>> able to factor anything it offerred in to what you've got now.
> Don't hesitate to dump things as you see fit. I assume you know a lot 
> more about practical JMS than I do :-) (haven't *really* used JMS before)

I'm no expert but two heads are always better than one.


View raw message