directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Alderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-894) Older concurrent changes are never replicated
Date Sun, 10 Jun 2007 01:36:26 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503138
] 

Martin Alderson commented on DIRSERVER-894:
-------------------------------------------

Hi David,

The scenario here is not "based on my copy of someEntry (1234), I want to change the phone
number", it's just "I want to change the phone number".

If the modification on A were an atomic "delete faxNumber 111; replace telephoneNumber 222"
then we have the scenario you mentioned.  Even in that case the current behaviour is very
bad in my opinion - the servers end up in an inconsistent state.  If the change is not going
to be allowed it would have to be rolled back on the originating server to maintain consistency
(or perhaps use some other strategy) but that's a separate issue.

The CSN values I used (e.g. A:1234) are a simplified representation of the real values.  In
reality we have 3 parts - the replica ID (A), the local timestamp (1234) and a local operation
sequence number, which is incremented at every operation (for the current replica) that occurs
in the same timestamp as the previous operation.  This ensures that the CSN's are globally
unique assuming the replica IDs are unique and don't change, and that time never jumps backwards
(although we can protect against that to a resonable degree too).

> Older concurrent changes are never replicated
> ---------------------------------------------
>
>                 Key: DIRSERVER-894
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-894
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: mitosis
>    Affects Versions: 1.5.0
>            Reporter: Martin Alderson
>
> When a (non-conflicting) change is made in two replica peer servers (A and B) at once,
A's changes are replicated to B, but B's changes are never replicated to A.  This leads to
inconsistent trees.  The two changes made can be totally unrelated (e.g. setting an attribute
in two separate objects).
> This is easy to reproduce by having two replica servers set up, disabling the network
link, making a separate change on each server,then re-enabling the network link.  Only one
server will have both changes, the other will only have its own change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message