You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "angela (JIRA)" <ji...@apache.org> on 2008/10/10 16:37:44 UTC
[jira] Created: (JCR-1800) JCR2SPI: lockmgr isn't aware about
external unlock (CacheBehavior.OBSERVATION)
JCR2SPI: lockmgr isn't aware about external unlock (CacheBehavior.OBSERVATION)
------------------------------------------------------------------------------
Key: JCR-1800
URL: https://issues.apache.org/jira/browse/JCR-1800
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-jcr2spi
Reporter: angela
Assignee: angela
Priority: Minor
issue occurring with CacheBehavior.OBSERVATION only:
the lock manager expects the jcr:lockIsDeep property to be created upon successful lock.
this however isn't the case since the time, we changed the Operation.persisted method to invalidate the affected states. consequently the mgr never started to listen on changes made to the jcr:lockIsDeep property and consequently wasn't aware of an external removal.
suggested fix:
force re-loading of the lock holding node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1800) JCR2SPI: lockmgr isn't aware about
external unlock (CacheBehavior.OBSERVATION)
Posted by "angela (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
angela resolved JCR-1800.
-------------------------
Resolution: Fixed
Fix Version/s: 1.5.0
> JCR2SPI: lockmgr isn't aware about external unlock (CacheBehavior.OBSERVATION)
> ------------------------------------------------------------------------------
>
> Key: JCR-1800
> URL: https://issues.apache.org/jira/browse/JCR-1800
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
> Reporter: angela
> Assignee: angela
> Priority: Minor
> Fix For: 1.5.0
>
>
> issue occurring with CacheBehavior.OBSERVATION only:
> the lock manager expects the jcr:lockIsDeep property to be created upon successful lock.
> this however isn't the case since the time, we changed the Operation.persisted method to invalidate the affected states. consequently the mgr never started to listen on changes made to the jcr:lockIsDeep property and consequently wasn't aware of an external removal.
> suggested fix:
> force re-loading of the lock holding node.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.