"bstansberry(a)jboss.com" wrote : anonymous wrote : | | 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. | | By default, region based marshalling is not enabled. You have to enable it if you want to use FIELD (which doesn't use MarshalledValue). But if you enabled it for FIELD and also had non-FIELD apps, yes, you'd have double marshalling. | You're just talking about double classloader-specific marshalling. Even if region-based marshalling is off, there will still be double-marshalling, i.e., Pojo -> a byte[] in your MarshalledValue, which is put in the cache. The CacheMarshaller then marshalls your MarshalledValue into a (bigger) byte[] for replication. Or is there something clever in your MarshalledValue class that just passes the byte[] payload in writeExternal()? "bstansberry(a)jboss.com" wrote : | Plus, having to change the cache config to support FIELD is crappy. | Agreed. "bstansberry(a)jboss.com" wrote : | anonymous wrote : 2. When an object is put in cache (cache.put()) I create a MarshalledValue and store the object as well as the thread's class loader. | | We have to be careful with the classloader ref, as leaking classloaders is a big no-no. It could be stored as a WeakReference, but need to think through how much that buys you versus not storing it at all and just using the TCCL. Particularly since on remote nodes the classloader ref will be null. | | I know in the standard AS use cases the read is always done with the correct TCCL. | True. Maybe just the TCCL approach would work then. "bstansberry(a)jboss.com" wrote : | anonymous wrote : 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. | | ... and throw away the ref to the byte[] -- i.e. no double memory usage. | Yes, definitely. Only one would exist at any time - the object ref or the byte array; never both. "bstansberry(a)jboss.com" wrote : | I'll need to find my scribbled design notes from when I thought about shared HTTP sessions, but I know that one thing that came out of my thinking was a need to flush the type system by converting everything back to a byte[]. This would be done on a redeploy, where we want to preserve cached data but the types are no longer usable. The MarshalledValue impl I was thinking of would have a method for that. I was assuming the session managment layer would walk the tree, get the marshalled values and invoke the "flush" method on them; if this is instead an internal detail of JBC there would need to be an API (probably on Node) to tell it to do the same thing. | Hmm. Let me think about it, but I can't really see a way for this to happen automatically. It would have to be an API call. "bstansberry(a)jboss.com" wrote : | 1) Shouldn't use the MarshalledValue for primitive types. | Or any other JDK objects - Dates, etc. "bstansberry(a)jboss.com" wrote : | 2) For collections, should probably just use it rather than doing something like trying to determine the type of all collection elements. | 2) Perhaps its a behavior that should be cache-wide configurable. So, if I'm storing a bunch of Sets whose elements are all Strings, I could turn this off. Yes, there should always be a way to disable this and allow manual spinning of marshalled values. I'd enable it by default though just to allow for lazy unmarshalling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4114867#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...