[OAK-1553] More sophisticated conflict resolution when concurrently adding nodes

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: core, documentmk, segment-tar
• Labels: concurrency scalability technical_debt
• Epic Link: DocumentMK technical debt
• Assignee: Unassigned
• Reporter: Michael Dürig
• Created: 17/Mar/14 19:44
• Updated: 09/Apr/19 14:58

Description

MicroKernel.rebase currently specifies: "addExistingNode: A node has been added that is different from a node of them same name that has been added to the trunk."

This is somewhat troublesome in the case where the same node with different but non conflicting child items is added concurrently:

f.add("fo").add("u1"); commit();
f.add("fo").add("u2"); commit();

currently fails with a conflict because fo is not the same node for the both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z

Issue Links

• blocks: OAK-1541 Concurrent creation of users chokes on intermediate paths

Sub-Tasks

• AbstractRebaseDiff: Implement refined conflict resolution for addExistingNode conflicts: Closed
• DocumentNS: Implement refined conflict resolution for addExistingNode conflicts: Open
• SegmentMK: Implement refined conflict resolution for addExistingNode conflicts: Open
• H2MK: Implement refined conflict resolution for addExistingNode conflicts: Closed