[ http://issues.apache.org/jira/browse/JCR-194?page=all ]
Marcel Reutegger updated JCR-194:
---------------------------------
Attachment: SharedItemStateManager.diff
Proposed patch on SharedItemStateManager.
The write lock is downgraded to a read lock before the listeners are notified.
That way, the SharedItemStateManager is effectively released for read access,
but does not allow modification while the synchronous listeners are notified,
giving them a consistent view of the transaction that just completed.
> dead lock while locking or unlocking nodes
> ------------------------------------------
>
> Key: JCR-194
> URL: http://issues.apache.org/jira/browse/JCR-194
> Project: Jackrabbit
> Type: Bug
> Components: locks
> Versions: 1.0
> Environment: Win XP, Sun JDK 1.5.0
> Reporter: Walter Raboch
> Assignee: Dominique Pfister
> Attachments: SharedItemStateManager.diff
>
> JackRabbit is still hanging on the Node.lock() or Node.unlock() function.
> ... everything fine until here...
> s13: 4
> s13: 5
> s13: 6
> s13: 7 -> unlock()
> s14: started.
> s14: 1 -> session.getRootNode()
> s15: started.
> s15: 1
> s16: started.
> I just find this failure during the first run (emtpy repository home
> directory). 2nd and 3th run are fine after killing the vm from first run, but
> with already initialized repository directory these time.
> 1. rm -rf repository.home
> 2. run -> hang
> 3. kill
> 4. run -> ok
> 5. run -> ok
--
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
