You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2005/07/06 15:54:12 UTC
[jira] Created: (JCR-164) SharedItemStateManager not properly synchronized
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
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 atomic.
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-164?page=all ]
Marcel Reutegger closed JCR-164:
--------------------------------
> 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
> Assignee: 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-164?page=all ]
Marcel Reutegger updated JCR-164:
---------------------------------
Attachment: SharedItemStateManager.patch
Proposed patch to SharedItemStateManager.
> 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-164?page=all ]
Marcel Reutegger reassigned JCR-164:
------------------------------------
Assign To: Marcel Reutegger
> 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
> Assignee: 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-164?page=comments#action_12315231 ]
Stefan Guggisberg commented on JCR-164:
---------------------------------------
+1, looks good.
> 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-164) SharedItemStateManager not properly synchronized
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-164?page=all ]
Marcel Reutegger resolved JCR-164:
----------------------------------
Resolution: Fixed
Commited at revision: 209608
> 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
> Assignee: 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 atomic.
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira