Related
I have a recurring database lock that I'm trying to understand.
I have a cron that is adding jobs to a queue. These jobs are then processed by various workers on different instances of production. All of them are importing data from a resource, and then adding/updating a table. Theoretically, there would never be two jobs writing to the same row, as the data is partitioned in such a way that this won't happen (jobs are created per provider, which means the id used in this table is unique).
This is what msyql is logging for the lock:
2023-01-12T10:49:41.876818Z 610974 [Note] InnoDB:
*** (1) TRANSACTION:
TRANSACTION 41621347924, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 610972, OS thread handle 22890357896960, query id 17518666 {instance} {app} updating
UPDATE offer SET timestamp = '2023-01-12 10:49:41' WHERE id = 17479128
2023-01-12T10:49:41.876850Z 610974 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3037 page no 11514 n bits 96 index PRIMARY of table `{app}_production`.`offer` trx id 41621347924 lock_mode X locks rec but not gap waiting
Record lock, heap no 16 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 4; hex 810ab5d8; asc ;;
1: len 6; hex 0009b0d35e55; asc ^U;;
2: len 7; hex 230002401d04c1; asc # # ;;
3: len 4; hex 8000e54d; asc M;;
4: len 17; hex 3330313032393431313035333030323630; asc 30102941105300260;;
5: len 3; hex 8fce3c; asc <;;
6: len 3; hex 8fce41; asc A;;
7: len 30; hex 3c7265736f75726365207265736f7572636569643d223330313032393431; asc <resource resourceid="30102941; (total 326 bytes);
8: len 1; hex 81; asc ;;
9: len 5; hex 99af18ac69; asc i;;
2023-01-12T10:49:41.877237Z 610974 [Note] InnoDB: *** (2) TRANSACTION:
TRANSACTION 41621347925, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 610974, OS thread handle 22894496118528, query id 17518667 {instance} {app} updating
UPDATE offer SET timestamp = '2023-01-12 10:49:41' WHERE id = 17821328
2023-01-12T10:49:41.877262Z 610974 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 3037 page no 11514 n bits 96 index PRIMARY of table `{app}_production`.`offer` trx id 41621347925 lock_mode X locks rec but not gap
Record lock, heap no 16 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 4; hex 810ab5d8; asc ;;
1: len 6; hex 0009b0d35e55; asc ^U;;
2: len 7; hex 230002401d04c1; asc # # ;;
3: len 4; hex 8000e54d; asc M;;
4: len 17; hex 3330313032393431313035333030323630; asc 30102941105300260;;
5: len 3; hex 8fce3c; asc <;;
6: len 3; hex 8fce41; asc A;;
7: len 30; hex 3c7265736f75726365207265736f7572636569643d223330313032393431; asc <resource resourceid="30102941; (total 326 bytes);
8: len 1; hex 81; asc ;;
9: len 5; hex 99af18ac69; asc i;;
2023-01-12T10:49:41.877643Z 610974 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3037 page no 10300 n bits 104 index PRIMARY of table `{app}_production`.`offer` trx id 41621347925 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 4; hex 810fee90; asc ;;
1: len 6; hex 0009b0d35e54; asc ^T;;
2: len 7; hex 22000240070d5b; asc " # [;;
3: len 4; hex 8000e54d; asc M;;
4: len 17; hex 3330313032393431313035333030323630; asc 30102941105300260;;
5: len 3; hex 8fce38; asc 8;;
6: len 3; hex 8fce3c; asc <;;
7: len 30; hex 3c7265736f75726365207265736f7572636569643d223330313032393431; asc <resource resourceid="30102941; (total 326 bytes);
8: len 1; hex 81; asc ;;
9: len 5; hex 99af18ac69; asc i;;
2023-01-12T10:49:41.878014Z 610974 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (2)
I have always sucked at sorting out deadlocking issues so looking for a bit of guidance.
Is this a table or a row lock? I'm using symfony 2.8 (don't ask) and it's doctrine packages.
Is there some way to disable the locking completely?
What can I read to better understand these logs?
I am updating a table and I seem to have a lock and it will not release. If i am reading this correctly the transaction 2 has been rolled back, but transaction 1 is still locking my table. Is there a way to force kill the transaction and roll it back?
*** (1) TRANSACTION:
TRANSACTION 421886199343912, ACTIVE 5 sec fetching rows
mysql tables in use 3, locked 3
LOCK WAIT 224788 lock struct(s), heap size 25419896, 2349612 row lock(s)
MySQL thread id 2967966, OS thread handle 140383641106176, query id 458710084 web.pub 192.168.2.57 user1 executing
INSERT IGNORE into file_search select distinct f.id, f.basename,f.filename,f.filesize as ...
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 2272 page no 2238466 n bits 456 index datatype_sensor_basename_idx of table `datastore`.`files` trx id 421886199343912 lock mode S waiting
Record lock, heap no 215 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 2; hex 8411; asc ;;
1: len 2; hex 8007; asc ;;
2: len 27; hex 41323032313331313231343030302e4c325f4c41435f4f432e6e63; asc fill.pdf;;
3: len 4; hex 0b103a5a; asc :Z;;
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2272 page no 2238466 n bits 456 index datatype_sensor_basename_idx of table `datastore`.`files` trx id 421886199343912 lock mode S waiting
Record lock, heap no 215 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 2; hex 8411; asc ;;
1: len 2; hex 8007; asc ;;
2: len 27; hex 41323032313331313231343030302e4c325f4c41435f4f432e6e63; asc file2.pdf;;
3: len 4; hex 0b103a5a; asc :Z;;
*** (2) TRANSACTION:
TRANSACTION 850180982, ACTIVE 33 sec updating or deleting
mysql tables in use 1, locked 1
LOCK WAIT 893 lock struct(s), heap size 123000, 16885 row lock(s), undo log entries 14091
MySQL thread id 3045015, OS thread handle 140383648741120, query id 458721905 web.pub 192.168.2.187 user1 updating
UPDATE files SET ... where id = 100
*** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 2272 page no 2238466 n bits 456 index datatype_sensor_basename_idx of table `datastore`.`files` trx id 850180982 lock_mode X locks rec but not gap
Record lock, heap no 215 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 2; hex 8411; asc ;;
1: len 2; hex 8007; asc ;;
2: len 27; hex 41323032313331313231343030302e4c325f4c41435f4f432e6e63; asc file3.pdf;;
3: len 4; hex 0b103a5a; asc :Z;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 2272 page no 2238466 n bits 456 index datatype_sensor_basename_idx of table `datastore`.`files` trx id 850180982 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 215 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 2; hex 8411; asc ;;
1: len 2; hex 8007; asc ;;
2: len 27; hex 41323032313331313231343030302e4c325f4c41435f4f432e6e63; asc A2021311214000.L2_LAC_OC.nc;;
3: len 4; hex 0b103a5a; asc :Z;;
*** WE ROLL BACK TRANSACTION (2)
You can kill a query/connection in MySQL using https://dev.mysql.com/doc/refman/8.0/en/kill.html
I also notice the (S)hared locks in use. These typically appear only when you are using FOREIGN KEYS. The recommendation to reduce deadlocks like this is to simply remove the FKs and implement in code instead.
I use insert ... on duplicate key updateto insert data in batches.
But I get a error when do it with more than one threads, actually just two threads do it.
The table is:
create table alarm {
id varchar(20) not null collate utf8_unicode_ci,
`date` date not null,
adas blob,
dsm blob,
bsd blob,
primary key(id, `date`)
) engine=innodb default charset=utf8
collate=utf8_unicode_ci
The insert statement is like:
insert into alarm(id, `date`, adas) values
('10001', 20220105, 0x1231231),
('10002', 20220105, 0xAFED001),
....
on duplicate key update
adas=concat(ifnull(adas,''), ifnull(values(adas),''));
The another insert statement is like:
insert into alarm(id, `date`, dsm) values
('10001', 20220105, 0x1231231),
('10002', 20220105, 0xAFED001),
('10008', 20220105, 0xAFED001),
('00008', 20220105, 0xAFED34),
....
on duplicate key update
dsm=concat(ifnull(dsm,''), ifnull(values(dsm),''));
sometimes, it will occur a dead lock error. The database log as following:
> myql show engine innodb status \G;
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-02-22 16:49:29 0x1fac
*** (1) TRANSACTION:
TRANSACTION 3902837, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 23 lock struct(s), heap size 1080, 28 row lock(s), undo log entries 31
MySQL thread id 85930, OS thread handle 17464, query id 34130124 DESKTOP-AJ1S2TF 192.168.20.191 root update
INSERT INTO device_alarm (did, `date`, dsm) VALUES('4044383', '20220222', 0x3a000a043078313012043078303220422945b8c9a832303f4031832f4ca60a685e40389ac7d2900642120a0e33303334333133313336333233301001),('4050503', '20220222', 0x38000a043078313012043078303229342db1321a493f4031ca4e3fa88b685e4038a1c7d2900642120a0e33303334333133323331333633371001),('2000023', '20220222', 0x3a000a0430783034120430783031202f29e08618af79fd36403159ddea39e9695c4038a5c7d2900642120a0e33303332333333313333333433351005),('4026821', '20220222', 0x38000a04307831301204307830322982aca7565f293f40316347e350bf725e40388cc7d2900642120a0e34313432353934413337333833331001),('4051611', '20220222', 0x3a000a0430783130120430783032201229377007ea94473f403113d38558fd545e403891c7d2900642120a0e33303334333133313339333633351001),('6493492', '20220222', 0x38000a043078303412043078303220432939d4efc2d65e4040317e54c37e4f5e5c40388ec7d29006421
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 682 page no 31 n bits 112 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902837 lock_mode X locks rec but not gap waiting
Record lock, heap no 42 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3430373336373431363336; asc 4073674;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d76; asc ; v;;
3: len 7; hex 5500000bba09b8; asc U ;;
4: len 30; hex 46000a04307830321204307830312a0430783031320430783030403149d1; asc F 0x02 0x01* 0x012 0x00#1I ; (total 576 bytes);
5: len 30; hex 38000a043078313012043078303229fe7bf0daa5e13e403124d1cb289672; asc 8 0x10 0x02) { >#1$ ( r; (total 412 bytes);
6: SQL NULL;
*** (2) TRANSACTION:
TRANSACTION 3902838, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
36 lock struct(s), heap size 3296, 39 row lock(s), undo log entries 48
MySQL thread id 85931, OS thread handle 8108, query id 34130125 DESKTOP-AJ1S2TF 192.168.20.191 root update
INSERT INTO device_alarm (did, `date`, adas) VALUES('1810534', '20220222', 0x46000a04307830321204307830322a0430783032320430783030404349a2410a9e42aa424051a2410a9e42aa42405895c7d2900662120a0e33353333333433303338333633381005),('2000041', '20220222', 0x46000a04307830321204307830312a04307830323204307830304020491920d1048a343f40511920d1048a343f40589ac7d2900662120a0e33303334333133313334333333391005),('1800684', '20220222', 0x48000a0430783032120430783031200b2a0430783031320430783030402e498bfcfa2136b24240518bfcfa2136b2424058a5c7d2900662120a0e33363338333433393336333133381005),('1030014', '20220222', 0x48000a043078303112043078303120062a0430783030320430783030402c4945b8c9a832ac38405145b8c9a832ac38405892c7d2900662120a0e33303331333433303333333433311005),('2000024', '20220222', 0x46000a04307830321204307830312a0430783032320430783030401f49284696ccb100374051284696ccb10037405897c7d2900662120a0e33303332333
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 682 page no 31 n bits 112 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902838 lock_mode X locks rec but not gap
Record lock, heap no 42 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3430373336373431363336; asc 4073674;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d76; asc ; v;;
3: len 7; hex 5500000bba09b8; asc U ;;
4: len 30; hex 46000a04307830321204307830312a0430783031320430783030403149d1; asc F 0x02 0x01* 0x012 0x00#1I ; (total 576 bytes);
5: len 30; hex 38000a043078313012043078303229fe7bf0daa5e13e403124d1cb289672; asc 8 0x10 0x02) { >#1$ ( r; (total 412 bytes);
6: SQL NULL;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 682 page no 136 n bits 120 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902838 lock_mode X locks rec but not gap waiting
Record lock, heap no 50 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3138373030383530303738; asc 1870085;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d75; asc ; u;;
3: len 7; hex 540000223f2ba1; asc T "?+ ;;
4: len 30; hex 46000a04307830321204307830312a0430783032320430783030402f4983; asc F 0x02 0x01* 0x022 0x00#/I ; (total 360 bytes);
5: len 30; hex 3a000a04307830341204307830312027292ae109bdfe0e4340317a8b87f7; asc : 0x04 0x01 ')* C#1z ; (total 602 bytes);
6: SQL NULL;
*** WE ROLL BACK TRANSACTION (1)
The lock is lock_mode X locks rec but not gap, it's too strange for me to undertand it. Why did the dead lock happen?
I'm trying to resolve an error involving deadlocks on one of our busy tables. I've read this SO question about deadlocks and while it makes sense, the query order doesn't seem to be the cause in my case.
Here's the abbreviated output of SHOW ENGINE INNODB STATUS;:
*** (1) TRANSACTION:
TRANSACTION 1 2611184895, ACTIVE 0 sec, process no 17501, OS thread id 140516779579136 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s)
MySQL thread id 211935717, query id 3146186174 [SERVER A] Searching rows for update
UPDATE images_unread_comments
SET unread = 0
WHERE user_id = 1 AND comment_id IN(1,2,3) AND unread = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 404976 n bits 632 index `users_unread_comments` of table images_unread_comments trx id 1 2611184895 lock_mode X waiting
Record lock, heap no 558 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67d888; asc g ;;
*** (2) TRANSACTION:
TRANSACTION 1 2611184892, ACTIVE 0 sec, process no 17501, OS thread id 140516774520576 updating or deleting, thread declared inside InnoDB 494
mysql tables in use 1, locked 1
6 lock struct(s), heap size 1216, 11 row lock(s), undo log entries 1
MySQL thread id 211935715, query id 3146186169 [SERVER B] Updating
UPDATE images_unread_comments
SET unread = 0
WHERE user_id = 1 AND comment_id IN(1,2,3) AND unread = 1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 404976 n bits 632 index users_unread_comments of table images_unread_comments trx id 1 2611184892 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 555 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67daf0; asc g ;;
Record lock, heap no 556 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67dadb; asc g ;;
Record lock, heap no 557 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67d940; asc g #;;
Record lock, heap no 558 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67d888; asc g ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 404976 n bits 632 index users_unread_comments of table images_unread_comments trx id 1 2611184892 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 558 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 4; hex 0001461a; asc F ;; 1: len 1; hex 01; asc ;; 2: len 6; hex 00000e67d888; asc g ;;
*** WE ROLL BACK TRANSACTION (1)
The thing I noticed is that the two SQL statements are identical; however one is being executed on Server A and the other on Server B. Regardless of why that is happening - why would this create a deadlock if both queries lock the same keys in the same order? Or am I misunderstanding the casue of deadlocks in the first place?
It seems that transaction 1 has performed another operation (insert?) in which it locked a gap in the index. It than waits for transaction 2 to perform the update, since 2 has locked the record with ID 1. Transaction 2 however can not proceed because transaction 1 holds a lock on the index. If you can isolate all SQL statements that are used in a transaction by this operation, we can see the exact reason for the deadlock
If following situation a bug in mysql?.
Mysql Version: mysql.x86_64 5.0.77-4.el5_4.1
Kernel: Linux box2 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
------------------------
LATEST DETECTED DEADLOCK
------------------------
100125 4:24:41
*** (1) TRANSACTION:
TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1
MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc # ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;;
*** (2) TRANSACTION:
TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1216, undo log entries 1
MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc # ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc # ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;;
*** WE ROLL BACK TRANSACTION (2)
------------
Sometimes the SHOW ENGINE INNODB STATUS can be hard to decipher because it only shows the current statement in the transaction. It does not show statements that occurred previously in the same transaction that may have acquired the locks that are actually being held.
In your case, a previous statement in transaction 2 acquired a shared lock on the row in question.
Then, transaction 1 attempted to acquire an exclusive lock on the same row, and is happily waiting for the shared lock to be removed.
Then, transaction 2, in another statement, attempted to acquire an exclusive lock on the same row. Classic deadlock. Neither transaction can finish.
One solution to help avoid such a deadlock would be to grab an exclusive lock on the row in transaction 2 with a SELECT FOR UPDATE statement, prior to the statement that's acquiring the shared lock.
I read something long ago, and not sure if it MIGHT be what you are running into as a result or not... without seeing code of the transaction of the current vs what it is conflicting with.
When processing your transactions, you should try to have them always do any locking in the same sequence... For an order / order detail / payments system, do the activities in the order listed as example here for all similar. If you have another process that tries its transaction in order of "Order detail / order", that CAN cause a deadlock.
One transaction is locking the order # first, then working the order detail. The other transaction locking the order detail first, then trying to get the order header.
HTH
Use SHOW ENGINE INNODB STATUS to determine the cause of the latest deadlock. That can help you to tune your application to avoid deadlocks.
Always be prepared to re-issue a transaction if it fails due to deadlock. Deadlocks are not dangerous. Just try again.