[
https://issues.jboss.org/browse/ISPN-5654?page=com.atlassian.jira.plugin....
]
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)