Re: [jr3] Synchronized sessions

[Thomas Müller <th...@day.com>]

Hi,

>> "consistency". I don't know of a relational database that allows you
>> to violate referential integrity, unique key constraints, or check
>> constraints - simply by using the same connection in multiple threads.
> jcr repository should have some point to do the constraints check as
> well. Should fail the operation if conflict found.

The easiest way to achieve internal integrity is to synchronize on an
object. Synchronizing on the session object is much easier, and costs
much less, than

1) allowing to corrupt internal states,
2) but then somehow detect the corruption
3) and then trying to fix such problems later on.

> Performance is not major concern, it's the design.

For me, performance _is_ a major concern. But reliability is more important.

> Synchronisation should be limited and should be applied to low level where necessary

There is an overhead for each "synchronize". If you synchronize on a
very low level, the cost potentially higher than if you synchronize on
a higher level. Because you have to synchronize more. Please note
"scalability" doesn't apply in this context: if you want to do stuff
concurrently, then use multiple sessions.

> instead blindly on session for everything.

I don't suggest to synchronize "blindly". I suggest to synchronize
"with open eyes" :-)

> Sync on session level could increase the deadlock as well.

No, the opposite: if every method is synchronized on the same object,
it will decrease the probability of deadlocks.

Regards,
Thomas