Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4ED751DC.8070606@apache.org>
Date: Thu, 1 Dec 2011 10:07:24 +0000
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: <dev@jackrabbit.apache.org>
Subject: Re: [jr3 microkernel] Write skew
References: <CAFBF1F9.98931%aklimets@adobe.com> <4ED63BEE.6010904@apache.org>
 <CAOFYJNYedNnWA4Z_NWAuGaJBEuav87fY330NXfKAf7_Apx-ruw@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNYedNnWA4Z_NWAuGaJBEuav87fY330NXfKAf7_Apx-ruw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 30.11.11 20:53, Jukka Zitting wrote:
>> 1) Does visible mean immediately visible on next access or visible after
>> refresh? The second case would work with snapshot isolation.
>
> That's up the implementation.
>
> Section 10.11.1 of JSR 283 [1] explicitly allows changes to become
> visible only after a refresh: "[...] items that do not have changes
> pending have their state refreshed to reflect the current persisted
> state, thus revealing changes made by other sessions."
>
> More generally about the write skew -issue; I don't think that's a
> common problem in practice. There aren't too many clients that
> explicitly interleave operations of multiple sessions within a single
> thread. And in a multithreaded setup a client would even with
> Jackrabbit 2.x need to use explicit synchronization to enforce more
> complex content constraints.

Ok, sounds reasonable to me as far as application constraints are 
involved. Note however, that for the same reason we are currently not 
able to guarantee node type consistency:

session1 = login()
session2 = login()

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

n2 = session2.getNode("n")
n2.addNode("foo")
n2.save()

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.

We could fix this by implementing Tom's test-and-set operator [1] in the 
microkernel.

Michael

[1] http://markmail.org/message/c32jpeoxklgcrybr

>
> [1] http://www.day.com/specs/jcr/2.0/10_Writing.html#10.11.1%20Refresh
>
> BR,
>
> Jukka Zitting