[
https://issues.apache.org/jira/browse/JCR-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-2855.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.2.3
Assignee: Jukka Zitting
Fixed in revision 1066059 by keeping count of active readers, and clearing the
activeWriterId when all reader and writer locks have been released. Merged to
the 2.2 branch in revision 1066061.
The activeWriterId needs to be left non-null for a downgraded write lock so
that a concurrent reader in the same transaction can re-enter the lock even if
there is another writer waiting. See JCR-2753 for more background.
> Writers blocked forever when waiting on update operations
> -----------------------------------------------------------
>
> Key: JCR-2855
> URL: https://issues.apache.org/jira/browse/JCR-2855
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.1.3, 2.2.1
> Reporter: Yoav Landman
> Assignee: Jukka Zitting
> Fix For: 2.2.3
>
>
> Thread 1 calls Session.save() and has a write lock.
> Thread 2 is in XA prepare() and is waiting on thread 1 in
> FineGrainedISMLocking.acquireWriteLock().
> Thread 1's save calls SharedItemStateManager.Update#end() and performs a
> write-lock downgrade to a read-lock, then (at the end of Update#end()) it
> calls readLock.release(). FineGrainedISMLocking.ReadLockImpl#release thinks
> activeWriterId is of the current transation and does not notify any writers
> (activeWriterId is not being reset on downgrade in what seems to be a related
> to JCR-2753).
> Thread 1 waits forever.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
