Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Peter :
Never say never again :-).
Using traditional techniques this was not posible
to implement. But using distributed coordination technology,
WANdisco Replicator does do multisite replication.
With WANdisco solution:
- replicator proxy pA for server A acts as the "coordinator" for User
A's check-in on file X
- replicator proxy pB for server B acts as the "ccordinator" for User
B's check-in for file X
- CVS clients and servers are not aware of the proxies.
- Using WANdisco's distributed coordination engine (DCone), pA and pB
agree upon an ordering. There are two possible orderings:
+ User A gets ahead of User B .
+ User B gets ahead of User A
- pA and pB both establish the same ordering using DCone. Note there
is no central coordinator here. No 2PC or merge gimmicks either.
Replicator's local locking
scheduler creates a deterministic partial order from the submitted commits.
- pA and pB submit the same ordering of events (A:B or B:A) to server A
and server B respectively.
- Let us say the ordering was A:B. Both server A and B will
indepedently reject User B's check in with an upto date failed message.
This is similar to how CVS server would
behave if two concurrent check-ins showed up on same file X.
- WANdisco replicator maintains it's own locking scheduler (not a
Distributed Lock Manager) to determine the best partial order
from a concurrency perspective and yet achieve "one copy equivalance".
Also there is a notion of quorum to allow more than 2 nodes! You can
have replicator at every distributed team site and use flexibile quorum
to acheive non-blocking ordering.
For further information take a look at WANdisco web page :
http://www.wandisco.com/cvs
Regards,
Rahul Bhargava
Peter Crowther
Thu Dec 2 14:47:15 GMT 2004 wrote:
> > From: Lahav Savir [mailto:LahavS at ixi dot com]
> > Does anyone has any idea how to create a two way replication of CVS
> > server,
>
> It's been discussed several times on this list. In summary: You can't.
> The counterexample is as follows:
>
> - User A edits file X on server A.
>
> - User B edits file X on server B.
>
> - User A commits file X on server A.
>
> - Before any replication can happen, user B commits file X on server B.
>
> The problem: Both commits will be allocated the same revision number.
> This cannot be resolved later.
>
> - Peter