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] http://cocoon.apache.org/2.1/installing/updating.html#Store
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
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
