[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-777) Eager cluster wide locks not cleaned upon rollback
[
https://jira.jboss.org/browse/ISPN-777?page=com.atlassian.jira.plugin.sys...
]
Mircea Markus edited comment on ISPN-777 at 11/22/10 6:58 AM:
--------------------------------------------------------------
As a solution: keep track of all the remote threads that run on a node. The lock cleanup
thread in TxTable would first interrupt all these threads and only then run the tx cleanup
command. This relies on the fact that an interrupted thread would not be able to acquire
locks anymore(needs to be enforced through a unit test).
was (Author: mircea.markus):
As a solution I'm thinking to either: keep track of all the remote threads that
run on a node. The lock cleanup thread in TxTable would first interrupt all these threads
and only then run the tx cleanup command. This relies on the fact that an interrupted
thread would not be able to acquire locks anymore(needs to be enforced through a unit
test).
Eager cluster wide locks not cleaned upon rollback
--------------------------------------------------
Key: ISPN-777
URL: https://jira.jboss.org/browse/ISPN-777
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 4.2.0.BETA1
Reporter: Vladimir Blagojevic
Assignee: Mircea Markus
Priority: Blocker
Fix For: 4.2.0.CR1
Attachments: CacheScheduledCounter.java, ISPN-777_output.txt
It seems that rollback sometimes does not release acquired eager locks. See attached test
program and run two JVM instances on the same machine. Program schedules a task to run
every 5 seconds. Tasks simply locks a key, gets the value, increases the value and puts it
back surrounded by begin/commit/rollback tx boundary.
Steps to reproduce (keep repeating steps until problem is encountered):
1) Kill one running instance.
2) Restart it
See attached example output of a run.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira