jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-314) Fine grained locking in SharedItemStateManager
Date Fri, 04 May 2007 08:02:15 GMT

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

Marcel Reutegger commented on JCR-314:

Oliver, thank you for your comment. However I do not see how a deadlock may occur between
jackrabbit and the DB used in a persistence manager. Deadlocks always require that locks are
acquired in a circular way. That's never the case between Jackrabbit and the DB. A call that
returns from the DB will always have released all DB locks. 

I'd appreciate if you were a bit more specific, e.g. provide a wait-for graph that shows a
deadlock 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.

I disagree. This would clearly be a bug in Jackrabbit and should rather be fixed than worked
around with timeouts.

> 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.

View raw message