jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-314) Fine grained locking in SharedItemStateManager
Date Mon, 14 May 2007 18:02:16 GMT

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

Jukka Zitting commented on JCR-314:

I briefly reviewed the patches, good work! I like how you've applied the strategy pattern.

My main concern is that this still doesn't address the concurrency limitations in the current
persistence managers. Should that be handled as a separate issue? A more general issue is
that this whole ISM core keeps getting more complex, and adding 1+2 new interfaces and all
the implementing classes doesn't really help things. I'm not sure what to do about that...

Also, it would be nice if we had at least a few parallel test cases for excercising such code.

> 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