[[serialization]]
= Working with Pivotal GemFire Serialization

To improve overall performance of the Pivotal GemFire In-memory Data Grid, Pivotal GemFire supports a dedicated
serialization protocol, called PDX, that is both faster and offers more compact results over
standard Java serialization in addition to works transparently across various language platforms (Java, C++, .NET).
Please refer to
http://geode.apache.org/docs/guide/11/developing/data_serialization/PDX_Serialization_Features.html[PDX Serialization Features]
and
https://cwiki.apache.org/confluence/display/GEODE/PDX+Serialization+Internals[PDX Serialization Internals]
for more details.

This chapter discusses the various ways in which _Spring Data for Pivotal GemFire_ simplifies and improves Pivotal GemFire's
custom serialization in Java.

[[serialization:wiring]]
== Wiring deserialized instances

It is fairly common for serialized objects to have transient data. Transient data is often dependent on the system
or environment where it lives at a certain point in time.  For instance, a `DataSource` is environment specific.
Serializing such information is useless, and potentially even dangerous, since it is local to a certain VM/machine.
For such cases, _Spring Data for Pivotal GemFire_ offers a special
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Instantiator.html[`Instantiator`]
that performs wiring for each new instance created by Pivotal GemFire during deserialization.

Through such a mechanism, one can rely on the _Spring_ container to inject and manage certain dependencies
making it easy to split transient from persistent data and have *rich domain objects* in a transparent manner.

_Spring_ users might find this approach similar to that of
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#aop-atconfigurable[`@Configurable`]).
The `WiringInstantiator` works just like `WiringDeclarableSupport`, trying to first locate a bean definition
as a wiring template and falling back to autowiring otherwise.

Please refer to the previous section (<<apis:declarable>>) for more details on wiring functionality.

To use this SDG `Instantiator`, simply declare it as a bean:

[source,xml]
----
<bean id="instantiator" class="org.springframework.data.gemfire.serialization.WiringInstantiator">
  <!-- DataSerializable type -->
  <constructor-arg>org.pkg.SomeDataSerializableClass</constructor-arg>
  <!-- type id -->
  <constructor-arg>95</constructor-arg>
</bean>
----

During the _Spring_ container startup, once it is being initialized, the `Instantiator` will, by default, register
itself with the Pivotal GemFire serialization system and perform wiring on all instances of `SomeDataSerializableClass`
created by Pivotal GemFire during deserialization.

[[serialization:instance-generator]]
== Auto-generating custom `Instantiators`

For data intensive applications, a large number of instances might be created on each machine as data flows in.
Out-of-the-box, Pivotal GemFire uses reflection to create new types, but for some scenarios, this might prove to be expensive.
As always, it is good to perform profiling to quantify whether this is the case or not.  For such cases,
_Spring Data for Pivotal GemFire_ allows the automatic generation of `Instatiator` classes which instantiate a new type
(using the default constructor) without the use of reflection:

[source,xml]
----
<bean id="instantiatorFactory" class="org.springframework.data.gemfire.serialization.InstantiatorFactoryBean">
  <property name="customTypes">
    <map>
      <entry key="org.pkg.CustomTypeA" value="1025"/>
      <entry key="org.pkg.CustomTypeB" value="1026"/>
    </map>
  </property>
</bean>
----

The definition above, automatically generates two `Instantiators` for two classes, namely `CustomTypeA`
and `CustomTypeB` and registers them with Pivotal GemFire, under user id `1025` and `1026`. The two `Instantiators` avoid
the use of reflection and create the instances directly through Java code.
