jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: [jr3] Synchronized sessions
Date Thu, 25 Feb 2010 09:05:14 GMT
Hi,

On Thu, Feb 25, 2010 at 9:22 AM, Stefan Guggisberg
<stefan.guggisberg@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 9:03 PM, Felix Meschberger <fmeschbe@gmail.com> wrote:
>> A big -1 (I already see the deadlocks in front of me)
>
> if there are deadlocks caused by such a change then the api's clearly being
> misused (i.e. concurrent use of session instances) and there's a risk of data
> corruption.

In fact, even concurrent use of sessions couldn't trigger deadlocks in
this case, since for a deadlock you'd need something that already has
locked a deeper repository resource to try locking the session. The
only cases I can think of where such a reverse order of locking is
possible are observation listeners and item state change
notifications.

It's feasible that we still have some lurking concurrency issues in
those areas (there were a few that we already fixed, see JCR-2443 for
an example), but I prefer deadlocks (that give you easily traceable
thread dumps) to potential cases of corrupted internal state (that are
notoriously difficult to troubleshoot).

So yeah, +1 to Thomas' suggestion. We shouldn't be relying on client
applications to maintain proper concurrency control.

BR,

Jukka Zitting

Mime
View raw message