jackrabbit-users mailing list archives

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

No worries. But I am not a Jackrabbit developer, so sometimes I may be
mistaking.

> It would be great if you could help me getting smarter. Two questions
>
> (1) Why is there Java side locking in the BundleDbPersistenceManager anyway?

I don't know the details of BundleDbPersistenceManager. However, this
question (or the more generic one about PMs) has been discussed
extensively in the past on the ml, so a search will reveal lots of
answers (I think Steffan is the guy)

> (2) If all locking is inside the individual persistence managers, what
> is the purpose of SharedItemStateManager locking?
>

Think about SharedItemStateManger as a 2nd level cache. A cache
without correct synchronization would not be a real cache. Basically,
it is meant to fulfill the spec requirements about item visibility
between different sessions.

bests,

./alex
--
.w( the_mindstorm )p.

> Thanks in advance
>
> Oliver
>
Mime
View raw message