jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "Transactional model of the Microkernel based Jackrabbit prototype" by MichaelDürig
Date Wed, 23 Nov 2011 17:46:43 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "Transactional model of the Microkernel based Jackrabbit prototype" page has been changed
by MichaelDürig:

New page:
The [[http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/ | Microkernel]] based JCR
implementation uses snapshot isolation with a relaxed first committer wins [1] 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 means are buried in the [[http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/store/CommitBuilder.java?view=markup
| code]] however.

Snapshot isolation exhibits write skew [1] which might turn out to be problematic for maintaining
consistency guarantees imposed by JCR. Consider the following events for node n which is initially
of type nt:unstructured:
session1 = login()
session2 = login()                                                         

n1 = session1.getNode("n")

n2 = session2.getNode("n")
Both sessions will successfully complete since for each of them the consistency property (nt:file
cannot have a child named "foo"). holds. The combined effect however will result in node n
being of type nt:file and having a child node foo.
To avoid these kind of inconsistencies, the Microkernel needs to impose additional checks
on transactions. A technique which avoids write skew effectively resulting in serializable
histories is described in [2]. 

[1] [[http://http://research.microsoft.com/apps/pubs/default.aspx?id=69541 | A Critique of
ANSI SQL Isolation Levels]]. Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth
O'Neil, and Patrick O'Neil. June 1995

[2] [[http://research.microsoft.com/apps/pubs/default.aspx?id=155638 | Eventually Consistent
Transactions]]. Sebastian Burckhardt, Manuel Fahndrich, Daan Leijen, and Mooly Sagiv. October

View raw message