jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Zeigermann" <oli...@zeigermann.de>
Subject Re: concurrent writes (JCR-314)
Date Mon, 04 Jun 2007 22:19:41 GMT
2007/6/5, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com>:
> On 6/5/07, Oliver Zeigermann <oliver@zeigermann.de> wrote:
> > 2007/6/4, Alexandru Popescu ☀ <the.mindstorm.mailinglist@gmail.com>:
> > > On 6/4/07, Oliver Zeigermann <oliver@zeigermann.de> 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
Mime
View raw message