Overview

You can control the serialization mode of Entry attributes when they are written or read from the space.

<space-config>
<!--0 - NATIVE SERIALIZATION, 1 LIGHT SERIALIZATION, 2 FULL SERIALIZATION, 3 COMPRESSED SERIALIZATION -
 default value for default schema is 0 -->
           <serialization-type>0</serialization-type>
</space-config>

When a client performs a space operation using a remote space (a space running in a different VM than the client program), the Entry/POJO data used with the write/update operation, or the template object data used with the read/take/notify operation is serialized and sent to the space. When the Entry/POJO or the template object arrives at the space, it is de-serialized and its data is stored in the space (write, update) using a generic data structure, or it is used to find a matching Entry (read/take/notify) in the space. When a read/take operation is called, the matching object data is serialized and sent back to the client program. When the matching object arrives into the client program VM, is it de-serialized and used by the client application.

The Entry/POJO field data and its meta-data information are extracted in run-time (marshaled), and transferred into the space using GigaSpaces generic portable Entry packet object. When sent back to the client as a result of a read/take operation, the object is de-marshaled and used by the client application.

When the Entry implements the Externalizable interface, readExternal and writeExternal are called, allowing you to efficiently control the stream transferred across the network.

writeObject and readObject If an Entry class implements the writeObject() and readObject() methods (or a POJO implements the Serializable interface) these methods are not called to serialize the data. If the Entry/POJO field implements the writeObject() and readObject() methods, these methods are called: public class MyEntry implements Entry { public PayLoadClass _myPayload; } /** writeObject() and readObject() are called for the PayLoadClass instance */ public PayLoadClass implements Serializable { private void writeObject(java.io.ObjectOutputStream out) throws IOException { // control the stream } private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException { // control the stream } }

It is possible to control the serialization of non-native fields. GigaSpaces provides different serialization methods for the fields: Native, Light, Full, and Compressed.

When using the .NET PONO API, the .NET classes implementing ISerializable are not serialized according to the .NET formatter. The .Net object field data and meta-data are inspected in real-time and transferred into the space using GigaSpaces generic portable Entry packet object. The serialization modes listed below are relevant only for Java Entry/POJO objects. .NET PONO users should use Native Serialization mode.

Supported Serialization Modes

Below are the supported serialization modes for non-native fields:

Serialization Mode	Description
Native Serialization (0)	Non-native fields including arrays, except for java.lang.* objects are transferred to and stored at the space as is (not as a java.rmi.MarshalledObject object). When using native serialization mode, the engine relies on the implementation of hashCode() and equals() methods when performing matching. You should make sure these are implemented correctly. In this mode the space JVM needs to have the Entry's user defined attribute classes as part of its classpath or the java.rmi.server.codebase. This mode is optimized for when accessing the space in embedded mode. When running in embedded mode, Entry attributes are passed by reference to the space. Extra caution should be taken with non-native none mutable fields such as collections (HashTable, Vector). Changes made to those fields outside the context of the space will impact the value of those fields in the space and may result in unexpected behavior. For example, index lists aren't maintained because the space is unaware of the modified field values. For those fields it is recommended to pass a cloned value rather then the reference itself. Passing a cloned value is important when several threads access the Entry fields - for example application threads and replication threads.
Light (1)	Non-native attributes including arrays, except for java.lang.* objects are transferred to and stored at the space as marshaled objects com.j_spaces.kernel.lrmi.MarshObject. With this mode there is no need to implement hashCode() and equals() when performing matching on non-native fields. In this mode the space JVM does not need to have the Entry's user defined field type classes as part of its classpath.
Full Serialization (2)	Non-native fields including arrays, except for java.lang.* objects are transferred to and stored at the space as marshaled objects (see Javadoc). This mode impacts the performance and should be used only when other serialization modes are not viable.
Compressed (3)	Non-native fields including arrays, except for java.lang.* objects Compressed before transferred into the space and stored within the space in compressed mode. This option is useful when the entry includes attributes with a relatively large amount of data such as XML data (DOM objects). This mode speeds up the access to remote space and reduces the space memory footprint when dealing with large entries. The compression algorithm using the java.util.zip package. You can control this parameter value using the com.gs.serialization parameter at the properties file or via the -Dcom.gs.serialization system property.

For additional optimization when serializing objects, refer to the Externalizable Support section.

Embedded Mode

• Native mode – non-native Entry field types are not serialized – the space stores the references of the non-native fields. This mode provides the best performance. In multi-threaded environments, be careful when accessing the non-native fields after their parent Entry has been stored into the space.

Reading and Changing entry in embedded mode without writing it back In embedded mode, GigaSpaces do not store the entry object reference, but stores its non-native references (complex attributes' references). When you know you might end up with multiple threads accessing the same object, you should clone the entry before you write it and continue and work with the cloned version. If you read object from the space and change it without writing it back, you might modify complex type object entry attribute data that another thread is holding its reference. One simple solution for this would be to use the exclusive read lock mode to block other threads from reading the same entry in the same time.

• Light/Full Serialization mode – non-native Entry field types are serialized – the space stores a clone of the fields object. This impacts the performance.

Remote mode

In remote mode, the Entry's non-native fields are serialized in any case, but the serialization mode determine how it is done:

• Native mode – non-native Entry fields are serialized using their native serialization. These are de-serialized at the space side before they are stored inside the space.
• Light mode – when non-native fields are serialized, they are wrapped with the MarshObject. When stored inside the space, these field are not de-serialized, but stored as MarshObjects. This improves performance, but does not allow querying of these fields.
• Full mode – supports the JavaSpace specification. When serialized, non-native fields are wrapped with a MarshalledObject. The MarshalledObject is de-serialized at the space side before it is stored, allowing you to query these fields. This mode is slow compared other options.
• Compressed mode – non-native fields are compressed before being sent to the space. These are stored in compressed mode.

With Externalizable implementations, only native serialization is supported. Externalizable is not relevant for embedded mode. In many cases this is the best way to boost remote space access.