OK, that makes sense. However, in my logs below the deadlock says it's
in two different caches. How does this work?
/K1 [key=e9228c01-b17e-49a5-bc7f-14c1541d9916, cache=TaskList]
K2 [key=e9228c01-b17e-49a5-bc7f-14c1541d9916, cache=MediaSets]/
On 14.09.22 11:59, Николай Ижиков wrote:
Basically, deadlock looks like the following:
First:
tx.start();
cache.put(1, 1);
cache.put(2, 2);
tx.commit();
Second:
tx.start();
cache.put(2, 2);
cache.put(1, 1);
tx.commit();
So if «first» locks key=1 and «second» locks key=2 concurrently both
process hangs trying to lock key=2(key=1) respectively.
14 сент. 2022 г., в 12:39, Thomas Kramer <[email protected]> написал(а):
Hi,
does the group here have any suggestion on this? I'm trying to find
the root of the deadlock we're getting on the production servers from
time to time.
So I'm trying to better understand why this can happen, and maybe
looking for sample code how to demonstrate such scenario in order to
better understand.
Thanks!
On 05.09.22 22:48, Thomas Kramer wrote:
I'm experiencing a transaction deadlock and would like to understand
how to find out the cause of it.
Snipped from the log I get:
/Deadlock detected:
K1: TX1 holds lock, TX2 waits lock.
K2: TX2 holds lock, TX1 waits lock.
Transactions:
TX1 [txId=GridCacheVersion [topVer=273263429, order=1661784224309,
nodeOrder=4, dataCenterId=0],
nodeId=8841e579-43b5-4c23-a690-1208bdd34d8c, threadId=30]
TX2 [txId=GridCacheVersion [topVer=273263429, order=1661784224257,
nodeOrder=14, dataCenterId=0],
nodeId=f08415e4-0ae7-45cd-aeca-2033267e92c3, threadId=3815]
Keys:
K1 [key=e9228c01-b17e-49a5-bc7f-14c1541d9916, cache=TaskList]
K2 [key=e9228c01-b17e-49a5-bc7f-14c1541d9916, cache=MediaSets]/
I can see that the same key (e9228c1) is used in a transaction on
two different nodes.
Ignite documentation says: /"One major rule that you must follow
when working with distributed transactions is that locks for the
keys participating in a transaction must be acquired in the same
order. Violating this rule can lead to a distributed deadlock."/
If the order of keys in the transaction must be in the same order,
how can the same key cause a deadlock here? Is it because it's in
two different caches? Maybe I don't fully understand how the
transaction lock works.
Is there a code sample that demonstrates a potential violation? How
can I now try to find in my source code where the issue happens on
both nodes?
Thanks,
Thomas.
