jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] Synchronized sessions
Date Thu, 25 Feb 2010 15:27:57 GMT
On Thu, Feb 25, 2010 at 3:59 PM, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi,
> 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>
>>>> 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 ....

why? (almost) every method would just need to synchronize on the session


> 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....
> Regards
> Felix
>> 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