title: Deadlock issue when transaction tries to accuire a lock it's already holding
body: <p>I've found a very confusing deadlock situation that I need help to understand.</p>
  
  <p>There are two transactions going on:<br>
  (2) holds a lock for the query <code>delete from myTable where id = NAME_CONST('p_id',10000)</code>. 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 <code>lock_mode X locks rec but not gap</code>.<br>
  (1) is waiting for this same lock, also for the query <code>delete from myTable where id = NAME_CONST('p_id',10000)</code>.<br>
  (2) is also trying go get this lock and MySQL detects a deadlock. </p>
  
  <p>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. </p>
  
  <p>It also looks like it's for the exact same query. </p>
  
  <p>Here is the table definition</p>
  
  <pre><code>create myTable (
    id int unsigned not null,
    value1 char(8) not null,
    value2 int unsigned,
    primary key (id, value1)
  );
  </code></pre>
  
  <p>and here is the information from <code>SHOW ENGINE INNODB STATUS\G</code></p>
  
  <pre><code>------------------------
  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)
  </code></pre>