directory-dev mailing list archives

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

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

David Jencks commented on DIRSERVER-894:
----------------------------------------

I'm not sure what semantics you expect here.  I think there's a case for not allowing one
of A or B's changes to succeed. My view is that A is saying, "based on my copy of someEntry
(1234), I want to change the phone number".  B is saying, "based on my copy of someEntry (1234),
I want to change the fax number".  If we allow A's changes (to state 1235), then the precondition
(namely state id is 1234) for B's changes is invalid and so B's changes should not be allowed.

One way to implement this idea is with versioned transactions, and idea pioneered back in
the 80's in the firebird database (then interbase).    

In any case I don't know of any way to implement any of these ideas reliably without a global
guaranteed ordering service, so that there is some way to agree whether A or B is "first".
 With the notation of the previous comment, what is supposed to happen when the "local time"
for A and B's changes are both the same time, 1235?

> 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