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