> On Thu, Mar 7, 2013 at 1:57 PM, Marcel Reutegger <mreut...@adobe.com> > wrote: > > not necessarily. e.g. if we take the unique UUID as an example, > > two sessions can proceed concurrently when they create nodes > > with different UUIDs, which is usually the case. the conflict only > > materializes when you create two nodes with the same UUID. > > But you can't know that in advance, so for example all XML imports > with at least one UUID in it would need synchronization. That's > probably a rare enough case not to worry about, but consider something > like adding a new write restriction on the root node. That of course > happens very rarely, but for conflict materialization to work properly > for such cases *all* writes would need to hit that materialization > point.
I forgot to illustrate how the UUID constraint is enforced in this case. assuming the uniqueness constraint is enforced with the p2 index implementation in oak, each node with a distinct UUID, will create a distinct index node for each UUID. creating those nodes will not result in a conflict as defined by Michael a while ago. only when two nodes with the same UUID are created, the index nodes will result in a 'addExistingNode' conflict. the second commit would therefore fail. not because a commit hook detected the violation, but because the MicroKernel implementation detected a conflict! thus the minimum requirement for the MicroKernel implementation is to ensure the conflict handling as currently defined (equivalent to what I still call snapshot isolation. though, I agree with Michael that it might not be 100% accurate because of our definition of NodeState.equals(). On the other hand, Tree doesn't have it...). the important point here is that I'd like us to consider updates to separate subtree as non-conflicting. regards marcel
