Current implementation

Base operations<= /h2>
Replication is meant to transpose a modification done on one server into= the associated servers. We should also insure that a modification done on = an entry in more than one server does not lead to inconsistencies.

As the remote servers may not be available, due to network conditions, w= e also have to wait for the synchronization to be done before we can valida= te a full replication for an entry. For instance, if we delete an entry on = server A, it can be deleted for real only when all the remote servers has c= onfirmed that the deletion was successful.

CSN and UUID

We will use two tags, stored within each entry, to manage the replicatio= n. The CSN (Change Sequence Number) stores when and where (which ser= ver) the entry was last modified. A replicated entry on 3 servers will have= the same CSN. Before replication they may be different. The UUID= (Universal Unique Identifier) is associated with an entry, and only on= e. So if we have an entry replicated on 3 servers, it will have one CSN<= /b> (as the entry is at the same version for all servers) and only one U= UID (as it's the same entry). The UUID is not currently used. = The CSN stored in the entry is used to prevent older modifications o= verwriting newer ones. Unfortunately this leads to inconsistent servers (s= ee DIRSE= RVER-894) - we need to check the CSN for each attribute instead= . Once this is fixed the CSN stored on each entry will no longer be= used.

Configuration
The replication system is a Multi-Master replication, ie, each server ca= n update any server it is connected to. The way you tell a server to replic= ate to others is simple :

<replicationInterceptor> <configuration> <replicationConfiguration logMaxAge=3D"5" replicaId=3D"i= nstance_a" replicationInterval=3D"2" responseTimeout=3D"10" serverPort=3D"= 10390"> <s:property name=3D"peerReplicas"> <s:set> <s:value>instance_b@localhost:1234</s:value> <s:value>instance_c@localhost:1234</s:value> </s:set> </s:property> </replicationConfiguration> </configuration> </replicationInterceptor>

Here, for the server instance_a" we have associated two replicas : *i= nstance_b and instance_c. Basically, you just give the list of r= emote server you want to be connected to.

The r= eplication interceptor

The MITOSIS service is implemented as an interceptor in the current vers= ion (1.5.4). The following operations are handled :

=09
add
=09
delete
=09
hasEntry
=09
list
=09
lookup
=09
modify
=09
move
=09
moveAndRename
=09
rename
=09
search

The hasEntry, list, lookup and search operations are only handled to pre= vent tombstoned (deleted) entries being returned.

Operations cl= asses

We are using Operation objects to manage replications inside the = interceptor. Here is the Operation classes hierarchy :

Each of the interceptor's method handling an entry modification will use= one of those classes to store the resulting modification.

Add operation

It creates a AddEntryOperation object, with a ADD_ENTRY operation= type (how useful is it, considering that we are already defined a specific= class for such an operation ???), an entry and a CSN.

The newly created entry will contain two new AttributeType :

=09
an entryUUID with a newly generated UUID
=09
an entryDeleted set to FALSE

If the added entry already exists in the current server, then we should = consider that the entry can't be added.

Currently, we check for more than the existence of the entry in the base= . Either the entry is absent, and we can add it, or it's present, and we sh= ould discard the new entry, throwing an error.

Or another option is to consider that the entry has been created on more= than one remote server, and then been created locally. We may have to repl= ace the old entry by the new one, even if they are different. This is the c= urrent implementation.

What if the entry already exists, but with a pending 'deleted' state ? T= his has to be checked.

As we may receive a Add request from a remote server - per replication a= ctivation -, we currently create so called glue-entries. There are n= ecessary if we consider that an entry is added when the underlaying tree is= absent. It does not make a lot of sense either, because the tree have nece= ssarily been created on the remote server, and the associated created entri= es have already been transmitted to the local server, thus we don't have to= create a glue entry.

Delete operatio= n

It creates a CompositeOperation object, which contains a Repla= ceAttributeOperation, as the entry is not deleted, but instead a ent= ryDeleted AttributeType is added to the entry, and a ReplaceAttribut= eOperation containing the injection of a entryCSN AttributeType,= with a newly created CSN.

So here are the operation content :

=09
ReplaceAttributeOperation
=09
entryDeleted, value TRUE
=09
ReplaceAttributeOperation
=09
entryCSN, with a new CSN

The delete operation should be a simple attribute Modification. Currentl= y, two requests are sent to the backend (one for each added attribute), whi= ch is useless.