[
http://jira.jboss.com/jira/browse/JBCACHE-1165?page=all ]
Manik Surtani resolved JBCACHE-1165.
------------------------------------
Resolution: Done
This has been fixed.
The main parts of the fix (all in the pessimistic lock interceptor) involve:
1) Each time a lock is acquired (a call to acquireLock() from within the lock() method) we
re-check whether the node we got a lock on is the same node that is in memory (checking
object identity) since another thread may have deleted the node in question, and then yet
another thread may have recreated a new node object in it's place rendering the lock
just acquired invalid.
2) Make sure removeNode calls have createIfNotExists set to true. Since lock objects
exist on the node, acquiring a lock for a remove is meaningless if the node does not
exist.
Endless loop in PessimisticLockInterceptor, sometimes seen as a
NodeNotExistsException
--------------------------------------------------------------------------------------
Key: JBCACHE-1165
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1165
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.0.0.GA, 1.4.1.SP4
Environment: Windows XP, Sun jdk150_06
Solaris 10
Reporter: Jacek Halat
Assigned To: Manik Surtani
Fix For: 1.4.1.SP7, 2.1.0.GA
Attachments: ConcurentPutRemoveTest.java, ConsoleOut.log
See ConcurrentPutRemoveTest
This sometimes manifests itself as an endless loop, and sometimes as a
NodeNotExistsException (on the putter thread) when concurrent puts and removes are
involved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira