[jboss-dev-forums] [Design of JBossCache] - Implicit marshalled values - a better way of handling region

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