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)