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’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" <[email protected]> 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
