Open jxblum opened 5 years ago
It turns out, Apache Geode (and by extension, Pivotal GemFire & Pivotal Cloud Cache (PCC)) may very well delegate to the PDX serialization mechanics to serialize objects passed to PdxWriter.writeObject(..)
.
I initially thought this was not the case because the Session Attributes were 1) first, encapsulated in a java.util.Map
object (as seen in the custom PdxSerializer
, the PdxSerializableSessionSerializer
, used to serialize the Session
object using PDX) and 2) the moment Geode processes a java.io.Serializable
object (e.g. like java.util.Map
), and the Serializable
object's type (e.g. again, Map
) is not PdxSerializable
(which a java.util.Map
would not be), nor is there a custom PdxSerializer
registered with the cache that knows how to serialize the object (e.g. again, a Map
), then Geode would uses Java Serialization to serialize the Map
and its contents.
However, I was informed that Geode identifies Collection
objects (like Map
) and inspects their contents. So, it may be the case that Geode will serialize objects (values) in the Map
(which would be the case for Session Attributes in the Spring Session
object) when the Map
object is passed to PdxWriter.writeObject("fieldName", mapObject)
.
I need to investigate the logic in PdxWriter.writeObject(..)
further (and again) to verify.
Currently, Spring Session for Apache Geode/Pivotal GemFire (SSDG) supports delegation when using Data Serialization to serialize both the
Session
and theSession Attributes
along with the corresponding attribute values.This gives users the ability to apply GemFire serialization semantics to their own application domain object types. However, the same strategy is not applied when using PDX Serialization to de/serialize the
Session
and its contents.This ticket sets out to enhance SSDG's PDX Serialization to support delegation.