directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Alderson" <Martin.Alder...@salfordsoftware.co.uk>
Subject Re: [Mitosis] random thoughts ...
Date Mon, 19 Jan 2009 16:19:12 GMT
> I would like to have something which works 100% first, then try to
> think about improvements.

That's reasonable.  I was trying to do this back in '07 by sticking tape over the current
implementation.  Sounds like you're on a better path now.


>> Note that both of these become much bigger issues if we want to support periodic
(as opposed to immediate) replication or incremental backup.
> 
> I guess that immediate replication when something change in any server
> is the best solution.

I personally don't have a use for periodic / delayed replication but it is currently on our
replication requirements page - http://cwiki.apache.org/confluence/display/DIRxSRVx11/Replication+Requirements


>> Using the current system (along with a fix for DIRSERVER-894) the
>> example above would require very little overhead for server B -
>> the minor change from server A would be sent over and then either
>> applied or discarded based on the CSN's at the time of the
>> modification.  The existing modifications don't need to be rolled
>> back / re-applied.
> 
> The main issue using this technic is to analyze in retrospect what
> would be the impact of a modification on the current server
> considering all the later modifciations : there are many possibilities
> that local modifications done after may be invalid.
> 
> Any idea on how to deal with that ?

Yeah, it does start getting very complicated to support everything.

One example is:

1. Server A and B start fully sync'd with no attr1.  The connection drops.
2. Server A does a replace attr1:A1
3. Server B does an add attr1:B1
4. The servers reconnect and replicate their changes.

Server A would just end up with attr1:A1,B1.  Server B needs some way of getting the same.
 I can only think of re-playing B's own logs after applying A's change really.  Not far off
what you're going for.


I think you're 100% right really.  It is definitely best to come up with something that works
then we can see if we can refine it a bit and optimise for some common cases.  I was only
worried about this new design being implemented only to have to re-design again later on to
get something optimal.

Martin



Mime
View raw message