You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Martin Alderson (JIRA)" <ji...@apache.org> on 2007/11/09 18:20:50 UTC

[jira] Commented: (DIRSERVER-894) Older concurrent changes are never replicated

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

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

I've just spent some more time looking at this issue (where did the last 7 months go?!) and realised that my previous solution didn't quite cover everything.  Specifically to ensure consistency we'd have to stop using EntryUtil.isEntryUpdatable - we need to resolve conflicts on a per attribute basis rather than looking at the modification and current entry as a whole.

The algorithm we need is more like: for each attribute in an incoming modification, apply it to our current entry if the CSN at the point when we think that attribute was last modified is less than the incoming CSN, otherwise ignore it.

Working out the CSN at the point an attribute was last modified is still the hardest part.  My earlier plan of just adding attribute name and modification type columns to the replication logs database won't work too well as a single row can represent multiple attribute modifications.


> 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
>             Fix For: 1.5.2
>
>
> 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.