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 Fri, 26 Feb 2010 13:38:18 GMT
Hi,

On Thu, Feb 25, 2010 at 19:14, Felix Meschberger <fmeschbe@gmail.com> wrote:
> Hi,
>
> On 25.02.2010 17:55, Marcel Reutegger wrote:
>> Hi,
>>
>> On Thu, Feb 25, 2010 at 15:49, Felix Meschberger <fmeschbe@gmail.com> wrote:
>>> Hi,
>>>
>>> On 24.02.2010 21:19, Thomas M├╝ller wrote:
>>>> Hi,
>>>>
>>>>> deadlocks
>>>>
>>>> I think it's relatively simple to synchronize all methods on the session.
>>>
>>> Yes, but this creates a big potential for deadlocks ...
>>>
>>>>
>>>>> If we want to make sessions thread-safe, we should use proper
>>>>> implementations.
>>>>
>>>> Yes, that's what I want to write: a proper implementation.
>>>
>>> I disagree that this would be a proper implementation.
>>
>> can you please elaborate what you think is a proper implementation in
>> this context?
>
> Just off-the-top-of-my-head: Using a better read-mostly guarding locking
> mechanism (i.e. readers don't block each other, writers need exclusive
> access [still not entirely save]); not at the "global" method level, but
> more intelligently guarding the shared data; not using the Session
> object itself for locking

that's pretty much what we do currently. we have read-write locks in
various places. the problem with that approach is that the sequence of
lock acquisition is very important. such fine grained locking is very
difficult to control and lead to various deadlock situation that were
hard to analyse and fix. IMO we should get rid of as many of those
locks as we can and synchronize on a more coarse grained level, which
is easier to maintain and more predictable.

regards
 marcel

> Regards
> Felix
>
>>
>> regards
>>  marcel
>>
>>>>
>>>>> any concurrent use of the same session is unsupported.
>>>>
>>>> The disadvantage of this is that there is no way to enforce correct
>>>> usage. In some cases, incorrect usage leads to data corruption. I
>>>> believe data corrupt is not acceptable, even if the user made a
>>>> mistake.
>>>
>>> Anything can go wrong -- and if people do the wrong things, well, fine,
>>> let them do ...
>>>
>>> And I don't say, we should not make Session thread-safe. But if we set
>>> out to do it, we should do it right. And just synchronizing all methods
>>> is just not right.
>>>
>>> Regards
>>> Felix
>>>
>>>
>>
>
>

Mime
View raw message