search

spring-projects / spring-session-data-geode

Spring Session support for Apache Geode and VMware Tanzu GemFire
https://projects.spring.io/spring-session/
Apache License 2.0
23 stars 28 forks source link

Consider PDX Serialization as a possible configuration option for SSDG in addition to the already existing use of GemFire/Geode's DataSerialization framework #2

Closed jxblum closed 6 years ago

jxblum commented 7 years ago

Original description from Spring Session Issue #493...

"_The initial implementation of Spring Session Data GemFire support made use of GemFire's PDX serialization framework. However, due to several limitations/problems when employing PDX to serialize HTTP Session data, particularly around adding new Session attributes (as first-class properties of the Session object itself) along with robust delta-propagation, the PDX effort failed._

_Based on the existing object model representing the (HTTP) Session state (specifically GemFireSession and GemFireSessionAttributes), it now maybe possible to utilize certain aspects of PDX, which has the distinct advantage of not having to modify the servers' CLASSPATH with application or Spring Session-specific types._

However, while PDX is more convenient and flexible, it is also slower than DataSerializable and does not necessarily prevent de-serialization on the server. It all depends on how the user has configured PDX on each individual server in the cluster along with the type of data access operations being performed by the application.

_For instance, certain OQL queries and GemFire Functions can cause a PDX instance to be de-serialized even when read-serialized is set to true. Therefore, if the Spring Session / application types are not on the server CLASSPATH when a data access operation triggers a deserialization, then a ClassNotFoundException will still be thrown._

_However, unlike DataSerializable, GemFire will prefer to keep PDX data serialized as much as possible, whereas it seems GemFire always deserializes DataSerializable objects, as is evident from GemFire Data Serialization section in the GemFire User Guide, where it states..._

"..while GemFire DataSerializable interface is generally more performant than GemFire's PdxSerializable, it requires full deserialization on the server and then reserialization to send the data back to the client."

The constant serialization/deserialization of data is a performance hit, and GemFire must always serialize data when replicating between peers in the cluster, replicating over WAN, transferring data between clients and servers, and when persisting and/or overflowing data to disk."

jxblum commented 7 years ago

Technically, the challenge(s) is/are...

  1. PDX Serialization does not completely support Delta Propagation without causing deserialization of the object since GemFire/Geode needs to deserialize the object to apply the Delta.

See the "Note:" under section "Data Serialization Options" in the Apache Geode User Guide here.

  1. Since PDX combined with Deltas causes a deserialization to occur, effectively nullifying the advantages of using PDX in the first place, the DataSerialization framework is really the only logical choice where Deltas are concerned.

So, I may consider offering an option when configuring serialization in Spring Session Data GemFire/Geode to...

A. Use DataSerialization with Delta Propagation.

B. Or use PDX (without Deltas).

1 of the primary UC of using PDX Serialization in GemFire/Geode is to avoid costly de/serializations and having to specifically declare application domain classes on the GemFire cluster servers CLASSPATH. Additionally, PDX enables Native Clients (i.e. C++/C#) to interoperate with Java-based GemFire cache client apps.

If Delta Propagation was enabled, this would cause the PDX serialized bytes to be deserialized every single time thus breaking interoperability by requiring corresponding Java types for the application domain classes on the GemFire Servers CLASSPATH.

So, a user can choose A or B, but not both.

jxblum commented 6 years ago

This was released in Spring Session Data GemFire/Geode 2.0.0.M2.