[
https://issues.apache.org/jira/browse/JCR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-314:
---------------------------------
Attachment: FineGrainedISMLocking-v2.patch
Here's a new version of FineGrainedISMLocking.
The performance should be better compared to the last version.
I'm not sure the test case is very representative though. Lot of monitor
contention happens between the write thread and readers when item states are
notified and the cache maps need to be accessed. I think finer grained locking
makes this situation even worse because it allows more concurrency on the
caches.
> 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
>
>
> 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.
