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-164) SharedItemStateManager not properly synchronized
Date Thu, 07 Jul 2005 12:20:14 GMT
    [ http://issues.apache.org/jira/browse/JCR-164?page=comments#action_12315228 ] 

Marcel Reutegger commented on JCR-164:

As a proposed solution I added synchronisation to the SharedItemStateManager (SISM) using
a ReadWriteLock. Multiple threads are allowed to read from the SISM as long as no other thread
is writing to the SISM. Only one thread is allowed to write to the SISM at a time.

read operations are the methods:
- getItemState()
- getNodeReferences()
- hasItemState()
- hasNodeReferences()

write operation in method:
- store()

The ReadWriteLock is a reentrant lock because the store operation also needs to read from
the SISM / cache.

> SharedItemStateManager not properly synchronized
> ------------------------------------------------
>          Key: JCR-164
>          URL: http://issues.apache.org/jira/browse/JCR-164
>      Project: Jackrabbit
>         Type: Bug
>   Components: core
>  Environment: svn revision: 209448
>     Reporter: Marcel Reutegger
>      Fix For: 1.0
>  Attachments: SharedItemStateManager.patch
> Some time ago we removed synchronized modifiers from the methods store() hasItemState()
and getItemState(). While some care has been taken to ensure the cache integrity, I think
the contract for the SharedItemStateManager (SISM) is now broken. The JavaDoc does not clearly
document this, but I think all relevant methods of the SISM working on ItemStates should be
> E.g. a call to hasItemState() should not return true for an ItemState that another thread
is currently adding in store(). Similarly a getItemState() should not return an ItemState
that is currenly added or modified in a store() operation.
> Currently I see two options:
> - Change the methods to synchronized again. This will actually serialize all calls to
the SISM.
> - Implement a more sophisticated synchronisation. E.g. multiple store operations can
still be allowed, as long as their ChangeLogs do not intersect. Retrieving ItemStates might
still be allowed while a ChangeLog is stored, as long as the ItemState to retrieve is not
part of the ChangeLog.
> Comments and suggestions are very welcome.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message