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] Updated: (JCR-314) Fine grained locking in SharedItemStateManager
Date Thu, 03 May 2007 13:00:30 GMT

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

Marcel Reutegger updated JCR-314:

    Attachment: FineGrainedISMLocking.patch

To drive this issue forward I created a patch that replaces the current rather hard coded
use of a ReadWriteLock in SharedItemStateManager with an abstraction layer that allows alternative

The way locking currently works is implemented in DefaultISMLocking and an initial implementation
of a more fine grained locking is available in FineGrainedISMLocking.

FineGrainedISMLocking does not allow concurrent writes but at least allows reads while a long
running write takes place and the read does not conflict with the write. I think this is the
most common use case (save a big file but still allow other sessions to read, which is currently
not possible).

All tests pass with both the DefaultISMLocking and the FineGrainedISMLocking.

The first patch only includes the structural changes moving away from the hard coded ReadWriteLock
in the SharedItemStateManager to the ISMLocking interface. It does not change the locking
semantics that are currently in place. The second patch is the proposal for a more fine grained
locking strategy.

Comments are welcome.

> 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