[infinispan-issues] [JBoss JIRA] Commented: (ISPN-879) Stale locks held when transactions are aborted by a transaction manager

[Mircea Markus (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576016#comment-12576016 ] 

Mircea Markus commented on ISPN-879:
------------------------------------

One way of doing this is by adding the check in the LocalTransaction object:
- on XAResource.rollback, before releasing the locks  call LocalTransaction.markForRollback()
- when LocalTransaction.putLookedUpEntry is called (that is when InvocationContext.putLookedUpEntries is called) check weather isMarkedForRollback ==true: if so throw an exception 

> Stale locks held when transactions are aborted by a transaction manager
> -----------------------------------------------------------------------
>
>                 Key: ISPN-879
>                 URL: https://issues.jboss.org/browse/ISPN-879
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Locking and Concurrency, Transactions
>    Affects Versions: 4.2.0.Final
>            Reporter: Manik Surtani
>            Assignee: Manik Surtani
>            Priority: Blocker
>             Fix For: 4.2.1.Final
>
>
> This is an issue with the way the LockManager attempts to acquire locks.  The crux of the problem is that when the LM waits on a lock that is already held, while within the context of a transaction, the transaction manager may decide to abort that transaction.  This could be for various reasons, including a transaction timing out.  Typically this would involve the transaction manager calling XAResource.end() followed by XAResource.rollback().  Unfortunately, this will almost always happen on a separate maintenance thread, and when the transaction is cleaned up, the user's original thread - still waiting for a lock - is not notified.  But the transaction is rolled back and as far as the transaction manager is concerned, all is well.
> Subsequently, when the lock is released, the original thread waiting on the lock acquires the lock, and continues.  However this transaction never completes since it has already "rolled back", leaving a stale lock in the system.
> The solution is after a lock is acquired, always check if it is in a transactional context and that the transaction is valid; if not, release the lock and throw an exception.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira