Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.39 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Thu, 1 Dec 2011 10:59:46 +0000
Subject: Re: [jr3 microkernel] Write skew
Thread-Topic: [jr3 microkernel] Write skew
Thread-Index: AcywGFbGCPRSv+eNSTyUu41uffM7Ww==
Message-ID: <98C3F472-B655-48FE-9E03-24EF9D943B10@adobe.com>
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>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

Am 30.11.2011 um 21:53 schrieb Jukka Zitting:

> Hi,
>=20
> On Wed, Nov 30, 2011 at 3:21 PM, Michael D=FCrig <mduerig@apache.org> wro=
te:
>> 1) Does visible mean immediately visible on next access or visible after
>> refresh? The second case would work with snapshot isolation.
>=20
> That's up the implementation.
>=20
> 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."

Ok. Thanks for the clarification.

I always thought, what Jackrabbit currently does is required ... So we (thi=
nking of Sling amongst other things) might have to adapt our event listener=
s to do a Session.refresh at the beginning of the onEvent method (in case l=
ong lived sessions are used).

>=20
> 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.

Sure. I think the main problem with long lived sessions I know of (in Sling=
 based applications) is with Observation Listeners which are quite isolated=
 and can be "fixed" easily -- there just has to be awareness.

Regards
Felix