On 27.2.13 12:50, Jukka Zitting wrote:
Hi,
On Wed, Feb 27, 2013 at 11:51 AM, Michael Dürig <mdue...@apache.org> wrote:
The problem is actually more subtle than that. The mechanism avoids refresh
being called from reentrant calls to any session scoped operation (that's
the reason for using a counter in perform). Otherwise we risk that a session
is refreshed while we are in the middle of a session scoped operation. This
can lead to very unpredictable test failures and bugs.
I'm not too worried about that, since we've always had that situation
in jackrabbit-core. The main problems this has caused are the various
deadlocks and corruptions that we've faced there, but in Oak those
should be non-issues since we have a much cleaner barrier between
session-local and repository-wide information. The worst that could
happen is a single session behaving a bit unexpectedly, and even that
should be pretty rare as most sessions never auto-refresh.
After a 2nd thought the situation is actually even worse than in JR2:
concurrent read operations might cause interfering refreshes. The
effects are completely unpredictable and may easily lead to the session
become completely corrupted. I agree that this probably only happens
very rarely but I think this makes the matter even worse: very sporadic,
erratic crashes that are nearly impossible to diagnose.
I see two ways out of this:
1) reconsider OAK-88, remove the auto refresh feature and rely on
clients to call refresh after they received an observation event.
2) Synchronize SessionDelegete.perform(), which effectively serializes
*all* JCR calls on a single session.
Michael
BR,
Jukka Zitting
