jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jira] Created: (JCR-1793) The abstract base classes in jcr-commons should be synchronized
Date Mon, 20 Oct 2008 12:37:34 GMT

Marcel Reutegger schrieb:
> Felix Meschberger wrote:
>> Hi,
>> Jukka Zitting schrieb:
>>> On Wed, Oct 8, 2008 at 4:06 PM, Felix Meschberger <fmeschbe@gmail.com>
>>>> I have the vague guts feeling, that this is not a good idea because it
>>>> creates too big synchronized blocks.
>>> Why would that be a problem? By definition we should not be having
>>> more than one concurrent thread accessing such blocks.
>> ehrm, because the synchronized blocks may become too big, which is
>> always fragile.
> IMO synchronizing access on the JCR API level is desirable because it is simple
> and effective. the synchronization issues we had so far were very difficult to
> debug or reproduce with a regression test due to the various levels of
> synchronization.

Not only that. One more issue -- probably the most problematic -- was
(and is) the mixture of different synchronization mechanisms, such as
Locks and JVM synchronization. In addition there are calls down and up
the "code layers" further complicating the situation and third the
mixture of synchronization granularity ...

> the only disadvantage I see right now is that there might be users that share a
> session among threads for read-only purpose. those will see a decrease in
> concurrency.
>> well, this is an interesting point ;-) While I think a service may
>> account for some client problems, it may not account for all problems.
>> Most notably, if a client is violating the contract, the client should
>> get into trouble
> I general I agree but when others get in trouble as well then something is wrong
> with the implementation. i.e. the repository should never get corrupted even
> when multiple threads use whatever method on a single session.

Well, it comes back to a question of contract, after all: The Session is
explicitly IIRC defined to not be thread safe. So this is the contract.
Of course an implementation of the API should be as stable as possible.
But synchronizing whole methods just to account for a few people not
abiding by the contract seems a bit overkill.

But then, I said "I have the vague guts feeling". This meens something
like "I am not sure, whether this is a good idea, but I cannot proof it" ;-)


View raw message