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

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

cheers
stefan

>
> 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
>>
>

Mime
View raw message