Transactional model of sessions

Sessions in Oak are based on a multi version concurrency control model using snapshot isolation with a relaxed first committer wins strategy. That is, on login each session is under the impression of operating on its own copy of the repository. Modifications from other sessions do not affect the current session. With the relaxed first committer wins strategy a later session will fail on save when it contains operations which are incompatible with the operations of an earlier session which saved successfully. This is different from the standard first committer wins strategy where failure would occur on conflicting operations rather than on incompatible operations. Incompatible is weaker than conflict since two write operation on the same item do conflict but are not incompatible. The details of what incompatible is somewhat dependent on the implementation of NodeStore.rebase() and the backend being used. See below.

Snapshot isolation exhibits write skew which can be problematic for some application level consistency requirements. Consider the following sequence of operations:

session1.getNode("/testNode").setProperty("p1", -1);
check(session1);
session1.save();

session2.getNode("/testNode").setProperty("p2", -1);
check(session2);
session2.save();

Session session3 = repository.login();
check(session3);

The check method enforces an application logic constraint which says that the sum of the properties p1 and p2 must not be negative. While session1 and session2 each enforce this constraint before saving, the constraint might not hold globally for session3.

See CompatibilityIssuesTest.sessionIsolation for a test case demonstrating this in runnable code.