Session refresh behaviour (was: [suggestion] introduce oak compatibility levels)

[Michael Marth <mm...@adobe.com>]

(Spawning this thread as it diverges away fro Stefan’s suggestion on signaling breaking changes)

Hi Thomas,

Looking at [1] I am surprised that the session would get refreshed in your example. 
Is that because in your example both sessions live in the same thread?

Thanks for clarifying!
Michael


[1] http://jackrabbit.apache.org/oak/docs/dos_and_donts.html



On 28/07/16 13:19, "Thomas Mueller" <mu...@adobe.com> wrote:

>Hi,
>
>>I agree if conflicts conceptually with MVCC. However: is there an actual
>>problem with the auto-refresh behaviour?
>
>Yes. For example with queries. If changes are made while iterating over
>the result of a query, the current behavior is problematic. Example code
>(simplified):
>
>    RowIterator it = xxx.createQuery(...).execute().getRows();
>    while (it.hasNext()) {
>        otherSession.getNode(...).remove();
>        otherSession.save();
>        Row row = it.nextRow();
>        Node node = row.getNode();
>        -> node can be null here!
>    }
>
>
>So basically the query result contains entries that get removed (by
>another session) while iterating over the result. So this can lead to
>NullPointerException and other strange behavior (you could get nodes that
>no _longer_ match the query constraints), depending on what you do
>exactly. Arguably it would be better if the session is isolated from
>changes done in another session in the same thread. By the way if using
>the same session to remove nodes and iterate over the result, the query
>result has to reflect the changes done by the session (I think this is
>required by the JCR spec).
>
>Regards,
>Thomas
>

Re: Session refresh behaviour (was: [suggestion] introduce oak compatibility levels)

[Michael Dürig <md...@apache.org>]

I think the case Thomas describes hits a auto refresh because another 
session in the same thread did some changes. See 
https://issues.apache.org/jira/browse/OAK-960 where this was introduced.

Michael


On 28.7.16 2:19 , Michael Marth wrote:
> (Spawning this thread as it diverges away fro Stefan\u2019s suggestion on signaling breaking changes)
>
> Hi Thomas,
>
> Looking at [1] I am surprised that the session would get refreshed in your example.
> Is that because in your example both sessions live in the same thread?
>
> Thanks for clarifying!
> Michael
>
>
> [1] http://jackrabbit.apache.org/oak/docs/dos_and_donts.html
>
>
>
> On 28/07/16 13:19, "Thomas Mueller" <mu...@adobe.com> wrote:
>
>> Hi,
>>
>>> I agree if conflicts conceptually with MVCC. However: is there an actual
>>> problem with the auto-refresh behaviour?
>>
>> Yes. For example with queries. If changes are made while iterating over
>> the result of a query, the current behavior is problematic. Example code
>> (simplified):
>>
>>    RowIterator it = xxx.createQuery(...).execute().getRows();
>>    while (it.hasNext()) {
>>        otherSession.getNode(...).remove();
>>        otherSession.save();
>>        Row row = it.nextRow();
>>        Node node = row.getNode();
>>        -> node can be null here!
>>    }
>>
>>
>> So basically the query result contains entries that get removed (by
>> another session) while iterating over the result. So this can lead to
>> NullPointerException and other strange behavior (you could get nodes that
>> no _longer_ match the query constraints), depending on what you do
>> exactly. Arguably it would be better if the session is isolated from
>> changes done in another session in the same thread. By the way if using
>> the same session to remove nodes and iterate over the result, the query
>> result has to reflect the changes done by the session (I think this is
>> required by the JCR spec).
>>
>> Regards,
>> Thomas
>>