directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Mitosis] Random thoughts (3)
Date Wed, 21 Jan 2009 08:29:22 GMT
Alex Karasulu wrote:
> On Tue, Jan 20, 2009 at 5:07 PM, Emmanuel Lecharny <>wrote:
> ...
> What about performances ? They are obviously terrible... If you think about
>> a server A on which you have injected 1 million entries, trying to replicate
>> with a server B on which a unique entry has been modified. We will have to :
>> - revert the million entries on A
>> - revert the modification on B
>> - transmit the million entry from A to B
>> - transmit the entry from B to A
>> - order the million and 1 entry on both server
>> - inject one million and one entry on A and B.
>> Obviously, we will have to transmit the million entry to B and to apply
>> them, but why should we revert and re-apply them on A? This is just a
>> waste...
>> How can we improve this ?
> One idea might be to send batches of replication events instead of one event
> at a time after the servers connect.
Yeah, that would help a bit at the margin. What I wanted to stress out 
is that the first proposal, though guaranted to success, is just 
impracticable. Using the second algorithm, we most certainly want to use 
standard LDAP requests, up to a point. If we have millions of entries to 
replicate, then it would also be a case we would want to switch to 
another method. I'm specifically thinking about a full init of a replica 
(a blank one) : it would be better to send everything as a big LDIF, zipped.
> ...
> 1) some entry are added on A and on B.
>> If any of those entries are 'colliding' (ie the intersection is not empty),
>> we have to manage some conflict. We have two different cases :
>> - both entries are the same : that's just ok, we just keep the older one.
> You should keep the newer one I think because the second add would have
> failed and you want the timestamps and creator information to match the
> first add.
Right. We need to delete the old entry, and replace it with the new one. 
what would be interesting is to switch to a modif operation in this 
case, to avoid many index to be changed (delete => some index 
modifications, and add => some more index modifications, when lot of 
them will remain unchanged if we simply compute a delta and update the 
previous entry by modifying only the necessary attributes).

cordialement, regards,
Emmanuel L├ęcharny

View raw message