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, 14 Sep 2007 08:58:32 GMT

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

Marcel Reutegger commented on JCR-314:
--------------------------------------

> What may be the consequences of allowing a reader to get a read lock in this situation
even if the writer's changelog includes
> the VERSION_STORAGE_NODE_ID ?

That's probably a bad idea. It may happen that a reader sees inconsistent data.

But anyway, I think a versioning operation will modify only the version storage root node
in rare cases. Merely when the version storage is nearly empty. As soon as there are enough
versions created the version storage root node has all possible child nodes (named 00, 01,
... ff) and is not modified anymore.

> 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-v2.patch, FineGrainedISMLocking.patch, ISMLocking.patch,
writes-per-second.jpg
>
>
> 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.


Mime
View raw message