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 mwaschkowski@gmail.com
 designates 64.233.162.232 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:references;
        b=bWIwJUH4/rCD7GlkxQacNIpWrSHxpWqqIS2zKAm/K0JFllJWReo4yjm4td4mlxHRyKId93OVQgNoz3zWek70RSF0VuTIGahumnDjXqVToHVEvOiTIJa5Ng14hQkC6exS9Z+XFwtjcg9NR51rL4donFoKyuWfYl6RbruuIjalEg0=
Message-ID: <76a6ebd00707230809m6dcdb514r30eb6c4aeddadbad@mail.gmail.com>
Date: Mon, 23 Jul 2007 11:09:29 -0400
From: "Mark Waschkowski" <mwaschkowski@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Isolation level inconsistency.
In-Reply-To: <1b0d43d00707230048t7ea1eea4u930a4060fb135edc@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_105148_24268374.1185203369919"
References: <469F8942.70403@yourmail.com>
	 <1b0d43d00707220747h4f1b0631x8f9544f8c0c83d73@mail.gmail.com>
	 <46A39841.9000204@yourmail.com>
	 <1b0d43d00707230048t7ea1eea4u930a4060fb135edc@mail.gmail.com>

------=_Part_105148_24268374.1185203369919
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Back after a long weekend away...

For the record, the only reasoning for the below case was that its easiest
to implement by the vendors. Here is one of my original examples:

Snip--
1) Get session and load a contact with name 'Joe'
2) Update the name property from 'Joe' to 'John'
3) Add a new contact
4) Query to get all the contacts and iterate through them
5) See nodes that have an updated state, but don't see any of the newly
added nodes! Now you have a strange mix all the previously persisted nodes,
nodes that have been updated in the session, but without any of the newly
added nodes!

Maybe I'm totally missing the point, but I can't fathom *why* the spec would
be written this way and really think it should just be one way or the other.

  ie. Either (ideally) respect the current session state and include ALL
session changes in the query results, or, if that is somehow
unacceptable/complicated/expensive operation etc., show me the persistent
state - just not some funky combination!
---end snip

I'm disappointed that there was so much dancing around the issues (by some
of the mailing list users) of why this should be considered proper or
reasonable, even though its odd, and has results that one would not expect.
Defending the spec because its the spec, or saying that its a *big change*
or *unfeasible* etc. is unhelpful when a new idea is proposed: -1 to those
of you doing so. At least some agreement on whether or not the idea is
reasonable or an improvement is needed before shooting suggestions down.

David said (re: a proposal for a more strict specification)
"I support your idea that from an API users perspective this behaviour could
be desirable."
Great.

David said (re: current spec)
"This particular limitation was originally put into the spec because a lot
of vendors believe that that it is hard to implement or they cannot
implement it at all. "
I can perfectly understand why this limitation might exist (many vendors
with implementations before JCR came along). However, one of the goals of
the spec was to make the API easy for developers, so that has to be
considered as well.

David said:
"As I mentioned I think one could suggest to loosen this contract by leaving
the query scope unspecified as a compromise."
Yes, would be an OK compromise, and one that I think would be better than
the current strange (and mandated) behavior. Ideally, a "particular
limitation" would be removed as the spec evolves, but at least it would
allow for the newer implementations to provide more sensible behaviors. I
would go further and suggest that a default behavior be stated within the
spec (either seeing persistent changes or not).

I'm going to go write to the 283 committee to update this part of the spec,
thanks to everyone for their comments.

Best,

Mark

On 7/23/07, David Nuescheler <david@day.com> wrote:
>
> Hi Ivan,
>
> Thanks for your summary.
>
> > When discussion will cool down I will summarize it and send a feedback
> to
> > jsr-283-comments@jcp.org.
> very good.
>
> > So far it looks like I hit the honey pot, I see a few use-cases from
> list
> > members in support of an idea and none against and it bother me.
>
> I support your idea that from an API users perspective this behaviour
> could be desirable.
>
> This particular limitation was originally put into the spec because
> a lot of vendors believe that that it is hard to implement or they cannot
> implement it at all. So you can consider that the current specification
> is what most vendors can implement.
> The section you originally quoted is in the spec on purpose, it is not
> an oversight.
>
> As I mentioned I think one could suggest to loosen this contract by
> leaving the query scope unspecified as a compromise.
>
> Personally, just from my gut feeling I cannot see a lot of support from
> the vendors for your proposed strict change, but feel free to submit
> it anyway, and it will certainly be considered.
>
> regards,
> david
>


-- 
Best,

Mark Waschkowski

------=_Part_105148_24268374.1185203369919--