jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Isolation level inconsistency.
Date Fri, 20 Jul 2007 08:37:17 GMT
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
>

Mime
View raw message