[jira] Resolved: (JCR-2855) Writers blocked forever when waiting on update operations

["Jukka Zitting (JIRA)" <ji...@apache.org>]

     [ 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