jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Narendra Sharma <narendra.sha...@gmail.com>
Subject Re: Persistence Manager - Query on Concurrency
Date Tue, 18 May 2010 16:03:04 GMT
Okay I believe you :)

The reason I asked this query is because I noticed lot of threads (70-75%)
BLOCKED in ISMLocking (tried with both DefaultISMLocking and
FineGrainedISMLocking). What I understand is that when a session is saved
the data gets written to persistence manager and the events are sent to
listeners. Some of these listeners are synchronous listeners like
SearchManager which in turn updates the Lucene index.

All the 70-75% threads are blocked in either acquireReadLock or
acquireWriteLock. The number of threads in my test are large (between 400 to
800). The question is why are there so many blocks? The answer according to
me is the threads are busy doing some operation either at persistence
manager layer or Lucene indexing. I am trying to debug that.
Meanwhile if anyone has any suggestion on debugging this (thread blocked)
issue, please share the same. Please share tips specific to JackRabbit and
not generic debugging tips for multithreaded apps.


On Tue, May 18, 2010 at 3:15 AM, Alexander Klimetschek <aklimets@day.com>wrote:

> On Mon, May 17, 2010 at 20:46, Narendra Sharma
> <narendra.sharma@gmail.com> wrote:
> > I am not sure if I understand it correctly. How would many sessions help
> if
> > there is single instance of Persistence Manager and methods in it are
> > synchronized. All threads will be blocked and only one will go through.
> >
> > This is very basic issue. So either I am missing something or I am not
> using
> > it the right way.
> Just believe us and all the people using Jackrabbit for years already ;-)
> A large part of Jackrabbit core is the management of transient and
> persistent item states (nodes and properties) within so-called item
> state managers. The relevant item state manager ensures
> synchronized/serialized calls to the persistence manager used.
> Regards,
> Alex
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message