On 28 Jan 2013, at 09:14, Galder Zamarreño wrote: > The reason we have storeAsBinary is due to lazyDeserialization. The latter > was a solution we designed to get around deserialization issues on app server > environments where JGroups would attempt to deserialize data with the wrong > classloader. > > The idea at the time was that deserialization would be delayed until a thread > with the correct classloader in context would come and deserialize data, > hence the name: lazy deserialization. This was needed in AS4/5/6. > > The design has always been the same, make sure data is kept in binary format > in the receiver and only deserialize when needed. > > This lazy deserialization is no longer needed in AS7 cos a particular plugin > is set in JBoss Marshaller which adds modular classloader info to serialized > data. So, when data arrives in the receiver, it can be deserialized directly > cos the classloader info allows for the correct classloader to be found. > > The naming change of lazyDeserialization to storeAsBinary was on purpouse and > precisely with the aim of it becoming a way to provide store-as-value > capabilities. The problem is that as you and Vladimir have spotted, this > doesn't really work like that. Thanks for putting this in context. Another reason for storing data in binary format is to reduce the number of times an object gets marshalled/unmarshalled. If the cluster is big enough and there's no key affinity, keeping data in binary format reduces the number of times it is marshalled/unmarshalelled.
Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org)
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
