Overview of Data Serialization
GemFire offers serialization options other than Java serialization that give you higher performance and greater flexibility for data storage, transfers, and language types.
All data that GemFire moves out of the local cache must be serializable. However, you do not necessarily need to implement
java.io.Serializable since other serialization options are available in GemFire. Region data that must be serializable falls under the following categories:
- Partitioned regions
- Distributed regions
- Regions that are persisted or overflowed to disk
- Server or client regions in a client/server installation
- Regions configured with a gateway sender for distributing events in a multi-site installation
- Regions that receive events from remote caches
- Regions that provide function arguments and results
Note: If you are storing objects with the HTTP Session Management Modules, these objects must be serializable since they are serialized before being stored in the region.
To minimize the cost of serialization and deserialization, GemFire avoids changing the data format whenever possible. This means your data might be stored in the cache in serialized or deserialized form, depending on how you use it. For example, if a server acts only as a storage location for data distribution between clients, it makes sense to leave the data in serialized form, ready to be transmitted to clients that request it. Partitioned region data is always initially stored in serialized form.
With GemFire, you have the option to serialize your domain objects automatically or to implement serialization using one of GemFire’s interfaces. Enabling automatic serialization means that domain objects are serialized and deserialized without your having to make any code changes to those objects. This automatic serialization is performed by registering your domain objects with a custom
PdxSerializer called the
ReflectionBasedAutoSerializer, which uses Java reflection to infer which fields to serialize.
If autoserialization does not meet your needs, you can serialize your objects by implementing one of the GemFire interfaces,
DataSerializable. You can use these interfaces to replace any standard Java data serialization for better performance. If you cannot or do not want to modify your domain classes, each interface has an alternate serializer class,
DataSerializer. To use these, you create your custom serializer class and then associate it with your domain class in the GemFire cache configuration.
GemFire Data serialization is about 25% faster than PDX serialization, however using PDX serialization will help you to avoid the even larger costs of performing deserialization.
** Serialization Options: Comparison of Features**
|Capability||GemFire Data Serializable||GemFire PDX Serializable|
|Implements Java Serializable.||X|
|Handles multiple versions of application domain objects, providing the versions differ by the addition or subtraction of fields.||X|
|Provides single field access of serialized data, without full deserialization - supported also for OQL querying.||X|
|Automatically ported to other languages by GemFire||X|
|Works with .NET clients.||X||X|
|Works with C++ clients.||X||X|
|Works with GemFire delta propagation.||X||X (See note below.)|
Note: By default, you can use GemFire delta propagation with PDX serialization. However, delta propagation will not work if you have set the GemFire property
read-serialized to “true”. In terms of deserialization, to apply a change delta propagation requires a domain class instance and the
fromDeltamethod. If you have set
read-serialized to true, then you will receive a
PdxInstance instead of a domain class instance and
PdxInstance does not have the
fromDelta method required for delta propagation.
GemFire serialization (either PDX Serialization or Data Serialization) does not support circular object graphs whereas Java serialization does. In GemFire serialization, if the same object is referenced more than once in an object graph, the object is serialized for each reference, and deserialization produces multiple copies of the object. By contrast in this situation, Java serialization serializes the object once and when deserializing the object, it produces one instance of the object with multiple references.