Retrofit storeAsBinary to allow implementation of JSR107 store by value ------------------------------------------------------------------------ Key: ISPN-2767 URL: https://issues.jboss.org/browse/ISPN-2767 Project: Infinispan Issue Type: Sub-task Components: Core API, Marshalling Affects Versions: 5.2.0.CR3 Reporter: Vladimir Blagojevic Assignee: Galder Zamarreño Fix For: 5.3.0.Alpha1 storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance: 1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation). 2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour. Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit. I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need: 1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ? 2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that *always* stores a byte[] and never caches the object representation?