jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jr3] Synchronized sessions
Date Thu, 25 Feb 2010 14:59:19 GMT

On 25.02.2010 10:05, Jukka Zitting 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.

So you also synchronize all Node/Item/Property methods and ensure that
for a given Item x, the same Item instance is always returned from all
getXXX methods ....

The longer I think of it, the longer I am scared and the longer I am
convinced, that this will be a situation, that has the potential of
getting my veto....


> 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

View raw message