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 Fri, 26 Feb 2010 16:51:46 GMT
Hi,

On 26.02.2010 14:38, Marcel Reutegger wrote:
> 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.

The problem is, that the code is very complicated, not to say convoluted
in places. Combined with mulitple locking mechanisms (JVM locks and
read-write locks) this creates much potential for deadlocks, right.

But to take the sledge hammer of synchronizing all methods out of the
box IMVHO is the wrong way to go.

Regards
Felix

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