[
https://issues.apache.org/jira/browse/JCR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495886
]
Marcel Reutegger commented on JCR-314:
--------------------------------------
Jukka, thanks for your comments.
> My main concern is that this still doesn't address the concurrency
> limitations in the current
> persistence managers.
You are right, the proposed changes will not solve the concurrency limitations
completely, but at least they should improve the current situation where no
reads are possible through the SISM when a write is taking place. I think
truely fine grained locking will not be possible with the current design and
thus would require major re-structuring in the jackrabbit core. Something I'd
rather like to postpone for a 2.0.
> [...] limitations in the current persistence managers. Should that be handled
> as a separate issue?
There are a number of other issues that are related. Even if persistence
managers are able to perform concurrent writes, the index will have to support
that too otherwise concurrent writes in the PM will be of limited use. And then
there's the question how to process (synchronous) events for concurrent writes?
> 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 actually didn't want to make it more complex but rather easier to understand.
I think the interfaces are of some value because they describe the locking
contract independant of the implementation. They also allow to easily try out a
different locking implementation / strategy.
> I'm not sure what to do about that...
I'm also not 100% happy with the proposed changes, but at least it solves the
most annoying problem with the SISM, that it locks up completely during a large
write.
I see the following options:
- We don't change anything right now and do it better the next time (NGP,
jackrabbit 2.0, ...)
- Redesign the core now to better handle concurrency
- Accept the patch ISMLocking.patch and discuss a locking
implementation/strategy that's better suited than the current one.
I'm obviously in favour of the last option ;) because it gives us the most bang
for the buck and is by far less risky than option two.
> Also, it would be nice if we had at least a few parallel test cases for
> excercising such code.
I agree. I already created some test cases that perform concurrent versioning
operations and basic content modifications. So if anyone is interested, feel
free to write more of them. The class AbstractConcurrencyTest and its sub
classes are a good starting point.
> 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.
