We had this discussion in Neuchatel, I'm bringing it up again here to solidify an
approach.
This pertains to JBCACHE-1231
Currently, we place direct object references in the cache. If the object in the cache is
in a defined region with it's own class loader, we do the following when marshalling
(and teh reverse for unmarshalling) the node (for replication, cache loading, etc etc).
1) serialize Fqn of the region
2) use the region's registered class loader to serialize cached objects
AFAIK - and please correct me if I am wrong - Brian, for HTTP sessions, your "cached
objects" are MarshalledValue instances that only unmarshall when you do a
MarshalledValue.get() as opposed to when the JBC marshaller unmarshalls.
I presume this means we have 2 levels of marshalling/unmarshalling, which could be
wasteful.
How about we do this:
1. In JBC I have my own "MarshalledValue" equivalent, which stores a reference
to the object, a byte array and a class loader (all of which can be built lazily).
2. When an object is put in cache (cache.put()) I create a MarshalledObject and store the
object as well as the thread's class loader.
3. When the object is requested (cache.get()) I inspect the object and if it is a
MarshalledValue, I return the object. If the object is not present, I deserialize the
byte stream, first with the associated class loader, and if one is not present, the
calling thread's class loader.
4. When replicating, the marshalled value serializes the object using the associated class
loader. When receiving a replication event, the cache marshaller just creates a
marshalled value with a null class loader and stores the byte array in the marshalled
value, letting this unmarshall lazily when requested, as in 3. above.
The impact of this is:
* Gets rid of ugly Fqn hacks when marshalling streams
* No double marshalling for HTTP sessions
* Transparent classloader switching based on calling thread
* Lazy deserialization of replication (== faster sync replication)
The downsides:
* May mean changing client code if the client already deals with MarshalledValues (such as
HTTP session clustering)
* Incompatible wire format with 2.0.0, but I am happy to break this as long as we provide
an old, backward compatible marshaller.
Thoughts?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114647#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...