jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [jr3] Synchronized sessions
Date Thu, 25 Feb 2010 11:25:44 GMT
On Thu, Feb 25, 2010 at 10:05, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.

+1

and I actually think we should do this already in 2.x. I've seen to
many concurrent use of sessions and data corruptions because of that,
even though we say it's not allowed. Fixing an inconsistent workspace
is a pain and finding the guilty code is usually very difficult.

regards
 marcel

> BR,
>
> Jukka Zitting
>

Mime
View raw message