More than one version of the same class may need to be serialized and deserialized. For example, a client may have an older version of a class, and the member to which it is connected may have a newer version of the same class.
Portable serialization supports versioning. It is a global versioning, meaning that all portable classes that are serialized through a member get the globally configured portable version.
You can declare Version in the configuration file
hazelcast.xml using the
portable-version element, as shown below.
<serialization> <portable-version>1</portable-version> <portable-factories> <portable-factory factory-id="1"> PortableFactoryImpl </portable-factory> </portable-factories> </serialization>
You can also use the interface VersionedPortable which enables to upgrade the version per class, instead of global versioning. If you need to update only one class, you can use this interface. In this case, your class should implement
VersionedPortable instead of
Portable, and you can give the desired version using the method
You should consider the following when you perform versioning.
- It is important to change the version whenever an update is performed in the serialized fields of a class, for example by incrementing the version.
- If a client performs a Portable deserialization on a field, and then that Portable is updated by removing that field on the cluster side, this may lead to a problem.
- Portable serialization does not use reflection and hence, fields in the class and in the serialized content are not automatically mapped. Field renaming is a simpler process. Also, since the class ID is stored, renaming the Portable does not lead to problems.
- Types of fields need to be updated carefully. Hazelcast performs basic type upgradings, such as
Example Portable Versioning Scenarios
Assume that a new member joins to the cluster with a class that has been modified and class' version has been upgraded due to this modification.
- If you modified the class by adding a new field, the new member's
putoperations will include that new field. If this new member tries to get an object that was put from the older members, it will get
nullfor the newly added field.
- If you modified the class by removing a field, the old members get
nullfor the objects that are put by the new member.
- If you modified the class by changing the type of a field, the error
IncompatibleClassChangeErroris generated unless the change was made on a built-in type or the byte size of the new type is less than or equal to the old one. The following are example allowed type conversions:
If you have not modify a class at all, it will work as usual.