To improve overall performance of the data fabric, GemFire supports a dedicated serialization protocol that is both faster and offers more compact results over the standard Java serialization and works transparently across various language platforms (such as Java, .NET and C++). This chapter discusses the various ways in which SGF simplifies and improves GemFire custom serialization in Java.
It is fairly common for serialized objects to have transient data.
Transient data is often dependent on the node or environment where it
lives at a certain point in time, for example a DataSource. Serializing
such information is useless (and potentially even dangerous) since it is
local to a certain VM/machine. For such cases, SGF offers a special Instantiator
that performs wiring for each new instance created by 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 @Configurable
).
The WiringInstantiator
works just like
WiringDeclarableSupport
, trying to first locate a
bean definition as a wiring template and following to autowiring
otherwise. Please refer to the previous section (Section 3.6, “Wiring Declarable
components”) for more details on wiring
functionality.
To use this Instantiator
, simply declare it
as a usual bean:
<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 container startup, once it is being initialized, the
instantiator
will, by default, register itself with the
GemFire system and perform wiring on all instances of
SomeDataSerializableClass
created by GemFire during
deserialization.
For data intensive applications, a large number of instances might
be created on each machine as data flows in. Out of the box, 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, SGF allows the automatic
generation of Instatiator
classes which instantiate
a new type (using the default constructor) without the use of
reflection:
<bean id="instantiator-factory" 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 generated two
Instantiator
s for two classes, namely
CustomTypeA
and CustomTypeB
and registers them with GemFire, under user id 1025
and
1026
. The two instantiators avoid the use of reflection
and create the instances directly through Java code.