Hi Brian,
what revision of jackrabbit are you using? according to the line numbers
in the thread dumps at least the SharedItemStateManager is not up to date.
there was an issue with locking some time ago.
http://issues.apache.org/jira/browse/JCR-194
is that fix included in your build?
Brian Moseley wrote:
hey all, any thoughts on this problem?
the weird thing is, each of these 10 threads is reading/writing
different nodes with different parents, eg
/test1/testfile.txt
/test2/testfile.txt
...
/test10/testfile.txt
so it's baffling me why anything would be sharing locks for operations
on different nodes.
i notice in the javadocs for WriterPreferenceReadWriteLock that a
deadlock can occur if a thread tries to re-acquire a read lock that it
already holds, if there are also waiting writers. i also see in the
thread dump that multiple threads are waiting to both read and write.
this is correct for the lock you mentioned, but jackrabbit uses the
reentrant variant of the lock which takes care of such situations.
i wonder if maybe some thread called two read methods on a node without
the lock having been released after the first one. is that possible?
or do the SISM locks apply to all operations in a workspace? can
somebody explain the locking behavior of SISM?
a thread holds a write lock while a change is stored in the persistence
manager. during that time no other thread can read from the SISM. events
are delivered while holding a read lock, which is the formerly hold
write lock downgraded to a read lock. thus synchronous (and of course
also asynchronous) listeners are able to read again.
well, that's basically it ;)
currently quite simple but works well.
regards
marcel
