Mailing-List: contact commits-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Wed, 23 Nov 2011 17:46:43 -0000
Message-ID: <20111123174643.92901.62145@eos.apache.org>
Subject: 
 =?utf-8?q?=5BJackrabbit_Wiki=5D_Update_of_=22Transactional_model_of_the_M?=
 =?utf-8?q?icrokernel_based_Jackrabbit_prototype=22_by_MichaelD=C3=BCrig?=
Auto-Submitted: auto-generated

Dear Wiki user,

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

The "Transactional model of the Microkernel based Jackrabbit prototype" pag=
e has been changed by MichaelD=C3=BCrig:
http://wiki.apache.org/jackrabbit/Transactional%20model%20of%20the%20Microk=
ernel%20based%20Jackrabbit%20prototype

New page:
The [[http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/ | Microk=
ernel]] based JCR implementation uses snapshot isolation with a relaxed fir=
st committer wins [1] strategy. That is, on login each session is under the=
 impression of operating on its own copy of the repository. Modifications f=
rom other sessions do not affect the current session. With the relaxed firs=
t committer wins strategy a later session will fail on save when it contain=
s operations which are incompatible with the operations of an earlier sessi=
on which saved successfully. This is different from the standard first comm=
itter wins strategy where failure would occur on conflicting operations rat=
her than on incompatible operations. Incompatible is weaker than conflict s=
ince two write operation on the same item do conflict but are not incompati=
ble. The details of what incompatible means are buried in the [[http://svn.=
apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/j=
ackrabbit/mk/store/CommitBuilder.java?view=3Dmarkup | code]] however.

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


n1 =3D session1.getNode("n")
n1.setPrimaryType(nt:file)
n1.save()

n2 =3D session2.getNode("n")
n2.addNode("foo")
n2.save()
}}}
Both sessions will successfully complete since for each of them the consist=
ency property (nt:file cannot have a child named "foo"). holds. The combine=
d effect however will result in node n being of type nt:file and having a c=
hild node foo.
                                                  =

To avoid these kind of inconsistencies, the Microkernel needs to impose add=
itional checks on transactions. A technique which avoids write skew effecti=
vely resulting in serializable histories is described in [2]. =


[1] [[http://http://research.microsoft.com/apps/pubs/default.aspx?id=3D6954=
1 | 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=3D155638 | Ev=
entually Consistent Transactions]]. Sebastian Burckhardt, Manuel Fahndrich,=
 Daan Leijen, and Mooly Sagiv. October 2011.