Skip navigation links

MySQL Forums :: InnoDB :: Deadlock issue when transaction tries to accuire a lock it's already holding


Advanced Search

Deadlock issue when transaction tries to accuire a lock it's already holding
Posted by: Andreas Wederbrand ()
Date: March 15, 2013 07:25AM

I've found a very confusing deadlock situation that I need help to understand.

There are two transactions going on:
(2) holds a lock for the query delete from myTable where id = NAME_CONST('p_id',10000). This is a lock by PRIMARY KEY although not the full key but a range. It looks like this is a full write lock to me when it says lock_mode X locks rec but not gap.
(1) is waiting for this same lock, also for the query delete from myTable where id = NAME_CONST('p_id',10000).
(2) is also trying go get this lock and MySQL detects a deadlock.

What I can't understand is why (2) has to acquire the lock again as it already holds it and it's a write lock (lock_mode X) in all cases.

It also looks like it's for the exact same query, ie, it both holds and waits for the same lock while executing the same query.

Here is the table definition

create myTable (
id int unsigned not null,
value1 char(8) not null,
value2 int unsigned,
primary key (id, value1)
);

and here is the information from SHOW ENGINE INNODB STATUS\G

------------------------
LATEST DETECTED DEADLOCK
------------------------
130313 14:46:28
*** (1) TRANSACTION:
TRANSACTION 75ACB8A3, ACTIVE 0 sec, process no 6110, OS thread id 139973945382656 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 5154970, query id 5201313618 192.168.0.2 user updating
delete from myTable where id = NAME_CONST('p_id',10000)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB8A3 lock_mode X waiting
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;

*** (2) TRANSACTION:
TRANSACTION 75ACB890, ACTIVE 0 sec, process no 6110, OS thread id 139973957895936 starting index read
mysql tables in use 1, locked 1
7 lock struct(s), hea
p size 1248, 6 row lock(s), undo log entries 4
MySQL thread id 5155967, query id 5201313625 192.168.0.1 user updating
delete from myTable where id = NAME_CONST('p_id',10000)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB890 lock_mode X locks rec but not gap
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 22371 page no 1598 n bits 104 index `PRIMARY` of table `db`.`myTable` trx id 75ACB890 lock_mode X waiting
Record lock, heap no 32 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 0005af3a; asc :;;
1: len 8; hex 2020202020202020; asc ;;
2: len 6; hex 000075acb890; asc u ;;
3: len 7; hex ea0000020d011e; asc ;;
4: len 4; hex 00000065; asc e;;

*** WE ROLL BACK TRANSACTION (1)

Options: ReplyQuote


Subject Views Written By Posted
Deadlock issue when transaction tries to accuire a lock it's already holding 918 Andreas Wederbrand 03/15/2013 07:25AM
Re: Deadlock issue when transaction tries to accuire a lock it's already holding 382 Rick James 03/16/2013 06:20PM
Re: Deadlock issue when transaction tries to accuire a lock it's already holding 406 Andreas Wederbrand 03/18/2013 01:01AM
Re: Deadlock issue when transaction tries to accuire a lock it's already holding 389 Rick James 03/20/2013 08:55AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.