[
https://issues.jboss.org/browse/ISPN-2291?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2291:
------------------------------------
Erik, I think the issues you describe in your last comment are fixed by ISPN-2383 in the
case where the local node is no longer the owner (because StaleTransactionCleanupService
doesn't roll back the transaction any more, instead we wait for the commit/rollback
from the originator).
On the other hand, the StaleTransactionCleanupService still rolls back the tx if the
originator has left the cluster. If the local node was running a lock or prepare command
for that tx (e.g. because the execution thread was waiting for a lock to be released by
another tx), that command would eventually acquire the lock and assign it to a stale
transaction. So we still need this part of your patch.
Tx rollback during state transfer has stale locks
-------------------------------------------------
Key: ISPN-2291
URL:
https://issues.jboss.org/browse/ISPN-2291
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta1
Reporter: Erik Salter
Assignee: Mircea Markus
Priority: Blocker
Fix For: 5.2.0.CR1
There are stale locks that happened when a transaction failed due to a replication
timeout to its peer node. The transaction contained grouped keys that were submitted to
the primary owner. During execution of one such transaction, there was a state transfer,
which changed ownership of these keys.
Here's an example flow:
The task executed and started a transaction. Since it was not the primary owner, it sent
a LockControlCommand to the new owner. This call timed out, and a rollback was issued.
The local transaction is completed, but subsequent attempts to lock this key fail.
The logs can be found here:
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.83/server.log.gz
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.84/server.log.gz
http://dl.dropbox.com/u/50401510/5.2.0.ALPHA3/lock/10.30.12.85/server.log.gz
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira