[infinispan-issues] [JBoss JIRA] (ISPN-5654) Make DeadlockDetectingLockManager aware of single-node locking

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-5654:
------------------------------------


Update 2: {{DeadlockDetectingInterceptor}} does set the remote lock intention, but the externalizer doesn't include it in the payload, instead it is reconstructed from the remote command, e.g. for a {{LockControlCommand}} it only includes the key(s) being locked. The collection of keys already acquired ({{locksAtOrigin}}) does get replicated, but it doesn't include keys for which the origin is not the primary owner, so DDLM will only detect a small fraction of the deadlocks with pessimistic locking. This is easy enough to fix, but the benefit from deadlock detection is quite small here, as users can and should modify their transactions to acquire locks in the same order and avoid deadlocks. 

With optimistic locking, {{CommandsFactoryImpl}} overwrites the {{locksAtOrigin}} collection on the remote node with {{PrepareCommand.getAffectedKeys()}}, which can cause false positives (in effect shortening the lock acquisition timeout to {{spinDuration}}). E.g. if tx1 and tx2 both want to write k1 (primary owner A) and k2 (primary owner B), when tx1 can't acquire lock k1 on A after {{spinDuration}} millis, DDLM will assume there's a deadlock, even if tx1 and tx2 weren't actually blocking each other and they could have executed successfully. In theory we could add a round of communication between the remote nodes executing the {{PrepareCommand}} to gather the actual locked keys and detect deadlocks without false positives, but that would certainly add complexity.

In conclusion, I'm going back removing {{DeadlockDetectingLockManager}}.

> Make DeadlockDetectingLockManager aware of single-node locking
> --------------------------------------------------------------
>
>                 Key: ISPN-5654
>                 URL: https://issues.jboss.org/browse/ISPN-5654
>             Project: Infinispan
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 8.0.0.Beta2
>            Reporter: Dan Berindei
>
> {{DeadlockDetectingLockManager}} seems to assume that the node that started a transaction acquires a local lock before replicating, which is wrong since we switched to locking only on the primary owner.
> In particular, {{isSameKeyDeadlock}} can probably be removed altogether.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)