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 Fri, 09 Nov 2007 17:20:50 GMT

    [ 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.


Mime
View raw message