Isolation Level is: Repeat Read(RR)
MySQL 5.6 DeadLock log:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-09-21 10:01:58 2b0d1fb0b700
*** (1) TRANSACTION:
TRANSACTION 19414864283, ACTIVE 0.448 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 9 lock struct(s), heap size 2936, 4 row lock(s), undo log entries 4
LOCK BLOCKING MySQL thread id: 8219895 block 8219858
MySQL thread id 8219858, OS thread handle 0x2b0d3978d700, query id 194299614451 10.111.76.151 test_trade update
insert into merchandise (merchandise_no, serial_no, `status`,
expand_status, quantity, title, describes)
values ('TR20220111100058055986', '20000666665555620435', 20,
10, 1, '',
'')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 9057 page no 5298 n bits 600 index `uk_serial_no` of table `test_trade`.`merchandise` trx id 19414864283 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 144 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 20; hex 3230323230363236313635343139373736383435; asc 20000666665555776845;;
1: len 4; hex 00f06178; asc ax;;
*** (2) TRANSACTION:
TRANSACTION 19414864275, ACTIVE 0.412 sec inserting
mysql tables in use 1, locked 1
8 lock struct(s), heap size 1184, 4 row lock(s), undo log entries 4
MySQL thread id 8219895, OS thread handle 0x2b0d1fb0b700, query id 194299614132 10.111.76.156 test_trade update
insert into merchandise (merchandise_no, serial_no, `status`,
expand_status, quantity, title, describes)
values ('TR20220111100058135388', '20000666665555630510', 20,
10, 1, '',
'')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 9057 page no 5298 n bits 600 index `uk_serial_no` of table `test_trade`.`merchandise` trx id 19414864275 lock mode S
Record lock, heap no 144 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 20; hex 3230323230363236313635343139373736383435; asc 20000666665555776845;;
1: len 4; hex 00f06178; asc ax;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 9057 page no 5298 n bits 600 index `uk_serial_no` of table `test_trade`.`merchandise` trx id 19414864275 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 144 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 20; hex 3230323230363236313635343139373736383435; asc 20000666665555776845;;
1: len 4; hex 00f06178; asc ax;;
*** WE ROLL BACK TRANSACTION (2)
Table merchandise has a primary key and auto-incre column "id", and a unique key column "serial_no". From the deadlock log, I know then reason of DeadLock: the insert intention X-lock of transaction(2) waiting the insert intention X-lock of transaction(1),and then insert intention X-lock of transaction(1) waiting then S-lock of transaction(2).
I do not know 'Why is there a S-lock'? Then column serial_no is unique key, and there is not select sql in my server.
I have a code snippet in hibernate, structured like below.
This method is a common method and when I use two different locks (In parallel stream) I end up having dead lock scenario. I am trying to understand the root cause of the dead lock.
[Spring/JPA/Hibernate/MySql]
#Transactional(isolation = Isolation.SERIALIZABLE)
public void someMethod(String lockName) { // Lock name can be of two types
jpaRepository.lock(lockName, TIMEOUT_10_SECONDS);
List<Object> values = jpaRepository.findByDate();
Integer sequence = jpaRepository.getNextSequenceValue(); // Fetches next value from sequence generator
//...... set sequence numbers to object
jpaRepository.updateSequence(); // A named query here to update sequence with latest value
jpaRepository.saveAll(); // JPA's persist call
}
Innodb status
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-03-24 00:05:03 0x16c113000
*** (1) TRANSACTION:
TRANSACTION 2000, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 2
MySQL thread id 54, OS thread handle 6131019776, query id 976 localhost 127.0.0.1 root update
/* mysql-connector-java-8.0.27 (Revision: e920b979015ae7117d60d72bcc8f077a839cd791 */ insert into SequenceId (invoice_id, post_processed_sequence_value, sequence_id, sequence_value) values (1648076703544, '79', '2000', 79)
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 3 page no 6 n bits 192 index invoice_id of table `sequenceid` trx id 2000 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3 page no 6 n bits 192 index invoice_id of table `sequenceid` trx id 2000 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) TRANSACTION:
TRANSACTION 1999, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 6 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 2
MySQL thread id 53, OS thread handle 6132133888, query id 977 localhost 127.0.0.1 root update
/* mysql-connector-java-8.0.27 (Revision: e920b979015ae7117d60d72bcc8f077a839cd791) */ insert into SequenceId (ref_id, post_processed_sequence_value, sequence_id, sequence_value) values (1648076703512, '50046', '1000', 50046)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 3 page no 6 n bits 192 index invoice_id of table `sequenceid` trx id 1999 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3 page no 6 n bits 192 index invoice_id of table `sequenceid` trx id 1999 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** WE ROLL BACK TRANSACTION (2)
When a transaction is executed in serializable isolation read statements acquire shared lock.
Please find the details below
Thread 1 tries to insert record by acquiring key. For insert there is no way we can hold a key. So mysql acquires a shared lock on the latest record before inserting.
Thread 2 tries to update the latest record and acquires the shared lock before inserting.
Now Thread 1 and Thread 2 are competing for the same lock and it causes deadlock.
I've created an application which gathers prices and stores it in a database.
The application runs with two threads. But now and then a deadlock occurs. I think it is because the treads insert a bulk of prices to the same table.
The table
[tripid | date | duration | price | garant | updatetime | persons | accommodationid]
The indexes
unique (tripid, date, duration, price, persons)
foreign key 'accommodationid' to table 'accommodation.id'
The query
insert into prices (tripid, date, duration, price, persons, accomodationid)
values ( 1 , 2016-6-4, 8, 200,2,32),
... a whole lot more ...
( 1 , 2016-7-4, 8, 200,2,32)
on duplicate key update price = values(price);
Becouse there can be 1000 values to insert in 1 query it takes some time. I think the deadlock occurs when the second thread wants to insert another 1000 values but the first one is not completed.
The innodb status
------------------------
LATEST DETECTED DEADLOCK
------------------------
2016-03-16 23:13:13 0xef8
*** (1) TRANSACTION:
TRANSACTION 3732195928, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 415, OS thread handle 7328, query id 10956855 ---(ip)-- --name-- update
insert into `prices` (tripid,`date`,`duration`,`price`,`garant`,`updatetime`,`persons`,`accommodationid`) values
(179881,'2016-03-18',2,206,'0','2016-03-16','1','119'),(179881,'2016-03-18',3,260,'0','2016-03-16','1','119'),(179881,'2016-03-18',4,313,'0','2016-03-16','1','119'),(179881,'2016-03-18',5,366,'0','2016-03-16','1','119'),(179881,'2016-03-19',2,206,'0','2016-03-16','1','119'),(179881,'2016-03-19',3,260,'0','2016-03-16','1','119'),(179881,'2016-03-19',4,313,'0','2016-03-16','1','119'),(179881,'2016-03-19',5,366,'0','2016-03-16','1','119'),(179881,'2016-03-20',2,206,'0','2016-03-16','1','119'),(179881,'2016-03-20',3,260,'0','2016-03-16','1','119'),(179881,'2016-03-20',4,313,'0','2016-03-16','1','119'),(179881,'2016-03-20',5,366,'0','2016-03-16','1','119'),(179881,'2016-03-21',2,206,'0','2016-03-16','1','119'),(179881,'2016-03-21',3,260,'0','2016-03-16','1','119'),(179881,'2016-03-21',4,313,
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 247 page no 1457 n bits 136 index keyGroup of table `travel`.`prices` trx id 3732195928 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (2) TRANSACTION:
TRANSACTION 3732195927, ACTIVE 0 sec inserting, thread declared inside InnoDB 4529
mysql tables in use 1, locked 1
15 lock struct(s), heap size 1136, 476 row lock(s), undo log entries 472
MySQL thread id 414, OS thread handle 3832, query id 10956852 ---(ip)-- --name-- update
insert into `prices` (tripid,`date`,`duration`,`price`,`garant`,`updatetime`,`persons`,`accommodationid`) values
(179880,'2016-03-18',2,185,'0','2016-03-16','1','1438'),(179880,'2016-03-18',3,217,'0','2016-03-16','1','1438'),(179880,'2016-03-18',4,249,'0','2016-03-16','1','1438'),(179880,'2016-03-18',5,279,'0','2016-03-16','1','1438'),(179880,'2016-03-18',6,312,'0','2016-03-16','1','1438'),(179880,'2016-03-18',7,343,'0','2016-03-16','1','1438'),(179880,'2016-03-18',8,375,'0','2016-03-16','1','1438'),(179880,'2016-03-19',2,185,'0','2016-03-16','1','1438'),(179880,'2016-03-19',3,217,'0','2016-03-16','1','1438'),(179880,'2016-03-19',4,249,'0','2016-03-16','1','1438'),(179880,'2016-03-19',5,279,'0','2016-03-16','1','1438'),(179880,'2016-03-19',6,312,'0','2016-03-16','1','1438'),(179880,'2016-03-19',7,343,'0','2016-03-16','1','1438'),(179880,'2016-03-20',2,185,'0','2016-03-16','1','1438'),(179880,'2016
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 247 page no 1457 n bits 72 index keyGroup of table `travel`.`prices` trx id 3732195927 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;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 247 page no 1457 n bits 136 index keyGroup of table `travel`.`prices` trx id 3732195927 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** WE ROLL BACK TRANSACTION (1)
------------
The Question
How do I avoid the deadlock?
I seem to have fixed it by first locking the table, then do the huge query and unlock it so the second thread gets acces.
LOCK TABLES prices WRITE;
insert into prices (tripid, date, duration, price, persons, accomodationid)
values ( 1 , 2016-6-4, 8, 200,2,32),
... a whole lot more ...
( 1 , 2016-7-4, 8, 200,2,32)
on duplicate key update price = values(price);
UNLOCK TABLES;
SHOW INNODB ENGINE STATUS shows me this and calls it deadlock:
LATEST DETECTED DEADLOCK
100923 22:29:21
* (1) TRANSACTION:
TRANSACTION 0 5335752, ACTIVE 0 sec, OS thread id 7992 inserting
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1024, 4 row lock(s), undo log entries 3
MySQL thread id 26, query id 14422 localhost 127.0.0.1 root update
insert into history_messagearguments (history_id, messageArguments_ORDER, messageArguments) values (69, 1, '1')
* (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335752 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000000000000048; asc H;; 1: len 6; hex 0000006fe7c5; asc o ;;
* (2) TRANSACTION:
TRANSACTION 0 5335748, ACTIVE 0 sec, OS thread id 6988 inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1024, 3 row lock(s), undo log entries 2
MySQL thread id 25, query id 14424 localhost 127.0.0.1 root update
insert into history_messagearguments (history_id, messageArguments_ORDER, messageArguments) values (71, 0, '0')
* (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335748 lock_mode X locks gap before rec
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000000000000048; asc H;; 1: len 6; hex 0000006fe7c5; asc o ;;
* (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335748 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 198 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 8; hex 8000000000000048; asc H;; 1: len 6; hex 0000006fe7c5; asc o ;;
* WE ROLL BACK TRANSACTION (2)
I cannot see why this is a deadlock. There is no line "WAITING FOR THIS LOCK TO BE GRANTED:" for transaction 1. If transaction 1 does not hold any locks, it cannot block anyone, so it cannot be part of a deadlock.
More theoretically, I cannot see condition 4 being satisfied as written here:
http://en.wikipedia.org/wiki/Deadlock#Necessary_conditions
The way I see it, MySQL should let transaction 2 continue. After it completes, transaction 1 can then go on.
Here (http://stackoverflow.com/questions/1851528/mysql-deadlock-explanation-needed) BrainCore wrote:
Transaction 2 gets "stuck" behind Transaction 1's request, a la FIFO queue.
Can anyone point me to MySQL documentation to confirm this? I find it hard to believe that transactions are strictly executed in the order they arrive.
Before all the questions about the table layout, isolation level etc. show up: I do not ask for help right now about resolving the deadlock. I ask how to read the SHOW ENGINE STATUS OUTPUT.
Read transactions 1 and 2:
Read from end to begining:
what type and why: lock_mode X locks gap before rec insert intention waiting
what is blocked:RECORD LOCKS space id 0 page no 179145 n bits 304 index fk_history_msgargs of table zvs_rkl_01_test.history_messagearguments trx id 0 5335748
WAITING FOR THIS LOCK TO BE GRANTED
InnoDB has problem with concurrent writes, especially if You insert data in the end of innodb table.