cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: svn commit: r169169 - in /cocoon/blocks/unsupported/template/trunk: java/org/apache/cocoon/template/jxtg/JXTemplateGenerator
Date Tue, 10 May 2005 17:39:03 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>> Vadim Gritsenko wrote:
>>> Sylvain Wallez wrote:
>>>> The transient store is meant as a cache for objects that aren't 
>>>> serializable, whereas the regular store has a memory front-end and 
>>>> some persistent filesystem swap, and therefore can only accept 
>>>> serializable objects.
>>> Not true. Regular store must accept all objects. See also [1].
>>> Vadim
>>> [1]
>> Hmm... although the old implementation *may* have been able to accept 
>> non-serializable objects, it has AFAIK never formally be defined in 
>> the general store contract,
> So now you will blame this bug on incomplete javadoc, huh? :-)

Well, do we have a better specification?

Here's what it says on the Store interface: "In some cases (like for 
example a cache) the data needs not to be persistent. Therefore with the 
two role TRANSIENT_STORE and PERSISTENT_STORE you get a store with 
exactly that behaviour."

We can consider that "the data needs not to be persisted" when it *can 
not* because it's not serializable.

>> and this is why we also have the transient store role.
> No, that's not necessarily the right conclusion. I say we have 
> transient store for objects which should not - or even must not! - be 
> persisted across system restarts - even if they are serializable!

True, but (feeling like doing biblical interpertation) a 
non-serializable object must not be persisted across system restarts, 
and this for a good reason: it isn't possible to store it :-)

>> Considering the current issues with the newer cache systems we use 
>> (that integrate both memory front-end and persistent swap)
> It does not mean that they are better, though. Even MRUMemoryStore is 
> more efficient.
>> and can't handle non-serializable objects, I think it would be better 
>> to make it clear that non-serializable objects have to go in the 
>> transient store.
> It is a serious backward incompatible change in contract. It might be 
> better if general store simply passes non serializable objects to the 
> transient store. Even better is fixing these new buggy stores. At the 
> very least, this can be fixed in Cocoon itself - by wrapping objects 
> into serializable holder.

Wow, a serializable holder? How can you do that when the wrapped objects 
are intrinsically not serializable? Or is it just for the serialization 
error to appear later, internally in the store, when the object is 
swapped to the filesystem?


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message