Model synchronization strategy contract. Model synchronization strategy instances are used to synchronize replicated instances of an arbitrary model. This is done by creating instances implementing this interface on participating processes, and then using them in the following manner.
First, assume for simplicity that there are two processes (A and B), each with a replica of a given model (a and b). Also assume that prior to using a synchronization strategy that the model is accurately and reliably replicated to A and B (i.e. a == b). Further, assume that for both A and B an instance of IModelSynchronizationStrategy is created (call them Sa and Sb) prior to any changes being made to either a or b.
On process A assume that the user makes a change to a via a (local) editor. Then the expected sequence of activities is as follows:
- Process A should synchronously call {@link #registerLocalChange(IModelChange)}. The IModelChange instance provided must be 1) not
null; and 2) Of a type that is appropriate for this synchronization strategy. - Process A should take the resulting {@link IModelChangeMessage}, serialize it (by calling {@link IModelChangeMessage#serialize()} and send themessage to remote processes (i.e. B).
- Process B should take the received byte array and call {@link #deserializeRemoteChange(byte[])} to create an IModelChange instance.
- Process B should then pass the IModelChange instance to {@link #transformRemoteChange(IModelChange)}. The synchronization implementation will then return an array of IModelChange instances (IModelChange []). These IModelChange instance should then be cast to the appropriate type, and applied to the local instance of the model (i.e. b). The {@link #transformRemoteChange(IModelChange)} metho will take the localchanges (previously registered with the synchronization strategy via {@link #registerLocalChange(IModelChange)}), and the remote changes provided via {@link #transformRemoteChange(IModelChange)}, and transform the changes into a set that will result in a synchronized local copy.
Note that clients should generally call the {@link #registerLocalChange(IModelChange)} and apply the IModelChangesreturned from {@link #transformRemoteChange(IModelChange)} on the same threadthat is responsible for modifying the underlying model. For example, if a document model is modified by an editor (via UI thread) then the UI thread should also synchronously call {@link #registerLocalChange(IModelChange)}, and the changes from {@link #transformRemoteChange(IModelChange)} should alsobe applied to the local document from within this same thread.
@since 2.1