2007/6/5, Alexandru Popescu ☀ <[EMAIL PROTECTED]>:
On 6/5/07, Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
> 2007/6/4, Alexandru Popescu ☀ <[EMAIL PROTECTED]>:
> > On 6/4/07, Oliver Zeigermann <[EMAIL PROTECTED]> wrote:
> > > I am not deeply into the problem, but why is there locking on the Java
> > > side anyway? It really should be possible to get along with DB locks
> > > only.
> > >
> > > Calling the DB from synchronized blocks always bears the danger of
deadlocks.
> > >
> >
> > Basically because the implementation of JCR is not required to work on
> > top of a RDBMS. Moreover, the persistence managers have been usually
> > created to be used over different persistence solutions (and over
> > different RDBMS, which have different locking support/mechanisms).
>
> If that is so, concurrency code really should be inside the individual
> persistence solutions and not inside the Jackrabbit core. If it is,
> there always is a deadlock hazard.
>
It is. Maybe before going further you should check the code. If you
have some suggestions I guess everybody would be happy to hear about
different approaches.
Oh. Sorry for being ignorant :(
It would be great if you could help me getting smarter. Two questions
(1) Why is there Java side locking in the BundleDbPersistenceManager anyway?
(2) If all locking is inside the individual persistence managers, what
is the purpose of SharedItemStateManager locking?
Thanks in advance
Oliver
