[
https://issues.jboss.org/browse/JBCACHE-1606?page=com.atlassian.jira.plug...
]
Jean-Pierre GRILLON commented on JBCACHE-1606:
----------------------------------------------
A simple correction should work:
- Add a parameter to Node.acquireAll, that will be used to store acquired locks (even if
an exception occurs)
- Add a try/finally block to PessimisticLockInterceptor, to use this new parameter, and
keep track of locks into variable acquired_locks
TimeoutException causes unreleased locks
----------------------------------------
Key: JBCACHE-1606
URL:
https://issues.jboss.org/browse/JBCACHE-1606
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Locking
Affects Versions: 1.4.1.SP13
Reporter: Jean-Pierre GRILLON
Assignee: Manik Surtani
Attachments: FT990Test.java
5 nodes in JBoss Cache, pessimistic locking:
/a/b/c1
/a/b/c2
/a/b/locked
/a/b/c3
/a/b/c4
And the node "/a/b/locked" is write-locked by another thread. Then try to
delete entire node "/a/b".
Node.acquireAll successfully acquires write-lock on "/a/b/c1" and
"/a/b/c2", but a TimeoutException occurs on "/a/b/locked" (which is
expected).
After this exception, locks on "/a/b/c1" and "/a/b/c2" are not
released.
Actually, Node.acquireAll shall return acquired locks, but in this case doesn't
return anything but throws an exception. So, previously acquired locks are not in
"cache.getLockTable()", and can't be released by UnlockInterceptor.
TestCase attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira