You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Julian Reschke <jr...@adobe.com> on 2012/05/07 17:34:38 UTC
session visibility
I was looking into
SessionRemoveItemTest#testRemoveItem3()
where we test that a separate session B can still read a node while the
other session A has removed but not saved it.
In this case, B is instantiated *before* the test setup actually created
the test node using session A. So session B doesn't see it not because
it was removed but because it wasn't there in the first place when the
session was created.
Sure enough, the test passes if we add a refresh() on B before the check.
I *believe* this is indeed a bug in the test case, but wanted to
double-check what the current behavior is indeed by design, and that
we're not planning to change it.
If this is true, we probably should open a JCR JIRA issue for tracking
these kind of problems in the (former) TCK (that is, jackrabbit-jcr-tests).
Best regards, Julian
Re: session visibility
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-05-07 19:20, Michael Dürig wrote:
>
>
> On 7.5.12 18:03, Julian Reschke wrote:
>> On 2012-05-07 18:50, Michael Dürig wrote:
>>>
>>> IIUC this is a slight change in semantics introduced by the underlying
>>> MVCC model. I created OAK-14 a while ago to document such issues. I
>>> suggest to add a test case to
>>> org.apache.jackrabbit.oak.jcr.CompatibilityIssuesTest to document this
>>> change in behaviour.
>>>
>>> Michael
>>>
>>> [1] https://issues.apache.org/jira/browse/OAK-14
>>> ...
>>
>> True, but it is a conforming behavior per JCR, right? Thus I believe the
>> test needs to be fixed...
>
> Not sure. Aren't both behaviours conforming? But it be more conforming
> ;-) when the test does an explicit refresh.
>
> Michael
Yes, sorry for the confusion. Both are conforming.
Re: session visibility
Posted by Michael Dürig <md...@apache.org>.
On 7.5.12 18:03, Julian Reschke wrote:
> On 2012-05-07 18:50, Michael Dürig wrote:
>>
>> IIUC this is a slight change in semantics introduced by the underlying
>> MVCC model. I created OAK-14 a while ago to document such issues. I
>> suggest to add a test case to
>> org.apache.jackrabbit.oak.jcr.CompatibilityIssuesTest to document this
>> change in behaviour.
>>
>> Michael
>>
>> [1] https://issues.apache.org/jira/browse/OAK-14
>> ...
>
> True, but it is a conforming behavior per JCR, right? Thus I believe the
> test needs to be fixed...
Not sure. Aren't both behaviours conforming? But it be more conforming
;-) when the test does an explicit refresh.
Michael
>
> Best regards, Julian
Re: session visibility
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-05-07 18:50, Michael Dürig wrote:
>
> IIUC this is a slight change in semantics introduced by the underlying
> MVCC model. I created OAK-14 a while ago to document such issues. I
> suggest to add a test case to
> org.apache.jackrabbit.oak.jcr.CompatibilityIssuesTest to document this
> change in behaviour.
>
> Michael
>
> [1] https://issues.apache.org/jira/browse/OAK-14
> ...
True, but it is a conforming behavior per JCR, right? Thus I believe the
test needs to be fixed...
Best regards, Julian
Re: session visibility
Posted by Michael Dürig <md...@apache.org>.
IIUC this is a slight change in semantics introduced by the underlying
MVCC model. I created OAK-14 a while ago to document such issues. I
suggest to add a test case to
org.apache.jackrabbit.oak.jcr.CompatibilityIssuesTest to document this
change in behaviour.
Michael
[1] https://issues.apache.org/jira/browse/OAK-14
On 7.5.12 16:34, Julian Reschke wrote:
> I was looking into
>
> SessionRemoveItemTest#testRemoveItem3()
>
> where we test that a separate session B can still read a node while the
> other session A has removed but not saved it.
>
> In this case, B is instantiated *before* the test setup actually created
> the test node using session A. So session B doesn't see it not because
> it was removed but because it wasn't there in the first place when the
> session was created.
>
> Sure enough, the test passes if we add a refresh() on B before the check.
>
> I *believe* this is indeed a bug in the test case, but wanted to
> double-check what the current behavior is indeed by design, and that
> we're not planning to change it.
>
> If this is true, we probably should open a JCR JIRA issue for tracking
> these kind of problems in the (former) TCK (that is, jackrabbit-jcr-tests).
>
> Best regards, Julian
Re: session visibility
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, May 7, 2012 at 5:34 PM, Julian Reschke <jr...@adobe.com> wrote:
> I *believe* this is indeed a bug in the test case, but wanted to
> double-check what the current behavior is indeed by design, and that we're
> not planning to change it.
Yes, I'd consider this an issue with the test case.
Note that there may well be some existing JCR client code out there
that makes similar cross-session assumptions, so it might be a good
idea to have an optional "auto-refresh" mode for such cases. I filed
OAK-88 to track that.
> If this is true, we probably should open a JCR JIRA issue for tracking these
> kind of problems in the (former) TCK (that is, jackrabbit-jcr-tests).
Agreed. It would be good to set up a container issue for all such TCK
problems so we'll have a better overview of the overall scope of the
issue.
BR,
Jukka Zitting