[jira] Commented: (JCR-314) Fine grained locking in SharedItemStateManager

["Oliver Zeigermann (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493368 ] 

Oliver Zeigermann commented on JCR-314:
---------------------------------------

As far as I can tell the FineGrainedISMLocking  implementation is prone to deadlocks. At least when a DB is used as storage. Such a deadlock can occur distributed between DB and the Jackrabbit locking. The DB can not resolve the deadlock, as internally it looks like there is none. A transaction timeout in the DB is the only way to resolve such a situation. 

In any case there should be a timeout for Jackrabbit locks. For one to to free locks that have never been freed, because some thread forgot to free them. Additionally, to make sure deadlocks between Jackrabbit and DB can be resolved quickly.


> Fine grained locking in SharedItemStateManager
> ----------------------------------------------
>
>                 Key: JCR-314
>                 URL: https://issues.apache.org/jira/browse/JCR-314
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3
>            Reporter: Marcel Reutegger
>         Attachments: FineGrainedISMLocking.patch, ISMLocking.patch
>
>
> The SharedItemStateManager (SISM) currently uses a simple read-write lock to ensure data consistency. Store operations to the PersistenceManager (PM) are effectively serialized.
> We should think about more sophisticated locking to allow concurrent writes on the PM.
> One possible approach:
> If a transaction is currently storing data in a PM a second transaction may check if the set of changes does not intersect with the first transaction. If that is the case it can safely store its data in the PM.
> This fine grained locking must also be respected when reading from the SISM. A read request for an item that is currently being stored must be blocked until the store is finished.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.