Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of
 the.mindstorm.mailinglist@gmail.com designates 209.85.146.177 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=iNTMrbCm4d9518uSHJ0uwmYt/E8Oi4bFqCOQFYIcFlmHz5lbZACaoYV2s+Vg39JIvIVzeIzRliPSAn2PEMLQsK3of+/B2y6gn8gzRDj3A43gdOlRsq7R13hXIfymbDQ/BIsHuMkipHsFSKRPlBdgaac/rzSc6JRN1J3RJUY3H4w=
Message-ID: <c6f400460707200137h8440267ga881533244fc45b1@mail.gmail.com>
Date: Fri, 20 Jul 2007 11:37:17 +0300
From: "=?UTF-8?Q?Alexandru_Popescu_=E2=98=80?="
 <the.mindstorm.mailinglist@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Isolation level inconsistency.
In-Reply-To: <46A07239.2060901@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070719233057.7B70810FB051@herse.apache.org>
	 <46A06850.4050303@gmx.de>
	 <c6f400460707200118r27425742sc3063f038d217779@mail.gmail.com>
	 <46A07239.2060901@gmx.de>

On 7/20/07, Julian Reschke <julian.reschke@gmx.de> wrote:
> Alexandru Popescu ? wrote:
> > I agree with both you comments here. However, I do feel that the OP
> > may be right (I confess that I was not facing this situation so far,
> > but this is probably because my app is a bit different).
> >
> > I would really appreciate if somebody would post on this thread a
> > scenario in which the current behavior is proving helpful (and I have
> > in mind the scenario posted here: searching for a John and getting a
> > Joe instead -- frankly speaking I would be totally surprised in real
> > life if I would be looking for my wife and getting somebody else
> > instead :-) ).
>
> I don't think the current JCR behavior was specced this way because
> there are uses cases needing it. It's simply a result of queries working
> against the persisted state (as the workspace methods), while the
> regular read messages don't.
>

Agreed... and this probably the root cause that makes it look like an
implementation specific detail, and not as something generic enough.

> I totally agree that this can cause surprising results, and the fix for
> that is not to do it. That is, save the changes first, or query + read
> using a separate session object. If this is not clear in the spec, let's
> fix *that* first.
>

Yep. We should probably try to make it more strong in the spec and
provide this level of information in there. At least this will
guarantee that the spec offers the solution if this behavior
represents a problem to the users.

bests,
./alex
--
.w( the_mindstorm )p.

> Best regards, Julian
>