Well, I found a good discussion about the underlying logic in https://issues.apache.org/jira/browse/JCR-2011 :) However, in my case, none of the tx changed the mixins that are applied to the node in question. So, does that mean that any concurrent changes to a node that has mixins on it are deemed as conflicting? Isn't that a bit too harsh or am I missing something?
Yoav Landman wrote: > > Hi, > > I am trying to understand the logic of merging mixing changes - > I see that the NodeStateMerger is failing a merge due do a difference in > the mixin type names. In practice, however, the content of the mixin type > namesets is identical between the overlayed state and the modified state > (same *names* references). But since the comparison of the 2 namesets > themselves is done by reference (NameSet does not override equals()) and > since the *namesets* references are different the merge ends up with a > StaleItemStateException. > > My question is - > Shouldn't the comparison of the mixin type sets be done by content, not by > the references of the namesets themselves? The relevant comments in > NodeStateMerger say: > "the mixins have been modified but by just looking at the diff we can't > determine where the change happened since the diffs of either removing a > mixin from the overlayed or adding a mixin to the transient state would > look identical..." > I am trying to understand this and how it applies to the current behavior, > but can't. Could someone shed some light on it? > > Thanks, > > Yoav > -- View this message in context: http://www.nabble.com/Understanding-mixins-merge-logic-tp23267598p23267777.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
