jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: enter() method for JCR implementation classes
Date Fri, 08 Mar 2013 13:32:32 GMT


On 27.2.13 12:50, Jukka Zitting wrote:
> Hi,
>
> On Wed, Feb 27, 2013 at 11:51 AM, Michael Dürig <mduerig@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
>

Mime
View raw message