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 Tue, 15 May 2007 07:59:16 GMT

    [ 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
> 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

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
> 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

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.

View raw message