Styjun

I am looking in to portable serialization in Hazelcast. In particular, I was interested in the VersionedPortable-interface. I created a scenario where two clients have different versions of the same class:

//VERSION 1
public class Vehicle implements VersionedPortable 
 private final String type;

 public Vehicle() this.type = ""; 
 public Vehicle(final String type) this.type = type; 

 public void setType(final String type) this.type = type; 
 public String getType () return this.type; 

 public void writePortable(PortableWriter writer) throws IOException 
 writer.writeUTF("type", type);
 

 public void readPortable(PortableReader reader) throws IOException 
 type = reader.readUTF("type");
 

 public int getFactoryId() return 1; 
 public int getClassId() return 1; 
 public int getClassVersion () return 1;


//VERSION 2
public class Vehicle implements VersionedPortable 
 private final String type;
 private final int tyres;

 public Vehicle() this.type = ""; this tyres = 0;
 public Vehicle(final String type, final int tyres) this.type = type; this.tyres = tyres; 

 public void setType(final String type) this.type = type; 
 public String getType () return this.type; 

 public void writePortable(PortableWriter writer) throws IOException 
 writer.writeUTF("type", type);
 writer.writeInt("tyres", tyres);
 

 public void readPortable(PortableReader reader) throws IOException 
 type = reader.readUTF("type");
 tyres = reader.readInt("tyres");
 

 public int getFactoryId() return 1; 
 public int getClassId() return 1; 
 public int getClassVersion () return 2;

I used these two classes in the following scenario:

• Hazelcast client with V1 creates a vehicle and stores it in an IMap: type=Porsche


• Hazelcast client with V2 updates the vehicle and stores it in the IMap: tyres=4


• Hazelcast client with V1 updates the vehicle and stores it in the IMap: type=Audi


• Hazelcast client with V2 reads the vehicle and prints it to the console: expected: Audi, 4; got: Audi, 0

Is my expectation wrong? I'm beginning to suspect that VersionedPortable is not meant for what I expected (supporting reading and writing different versions of the same object in a single IMap).

Some code on Github (line 95) and another SO-post (see third bullet) seem to point in that direction.

The other post you refer to has it right -- your V1 code only knows about the type field, and so any write done by V1 will only write the type field and not the tyres field. Since your V1 object doesn't know about tyres, it won't preserve the value that was written there by V2 code during a previous update.

The good news is that your V1 code can read objects written by the V2 code, without requiring any modification. (NOTE: edited to correct statement, V1 can read objects written by V2, I mistyped and said write in the original)

V2 code needs to be aware that as long as V1 clients are still part of the system, it has to be prepared to see entries that have no value there. It might be useful to set a default value to use when no value is found.

In some cases, you may want to enforce a restriction that the reader checks the version of the object being read, and if it is from a later version of the code, prohibit updates to the object. In this way you can ensure that you won't lose updates from newer code, perhaps throwing an exception that will result in the user seeing a warning or error that they are not running the latest client code, and should update in order to have write access to the requested object.