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.
>> 
>> 
>> 

Reply via email to