Bug #72011 | Deadlock with 3 transactions (inserts) | ||
---|---|---|---|
Submitted: | 11 Mar 2014 16:06 | Modified: | 17 Mar 2014 21:33 |
Reporter: | Martin Arrieta (OCA) | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.6 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | deadlock |
[11 Mar 2014 16:06]
Martin Arrieta
[11 Mar 2014 16:11]
Martin Arrieta
Sent too soon :) . This is the URL: http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html
[17 Mar 2014 19:37]
Sveta Smirnova
Thank you for the report. > it will generate a deadlock only for tx3 and tx2 will succeed. What do you mean by "tx2 will succeed"? When deadlock happens one transaction succeed and one rolled back. This is expected behavior. There can not be deadlock for single transaction.
[17 Mar 2014 19:46]
Martin Arrieta
Sveta. "tx2 will succeed" = tx2 will be able to insert the row. When tx1 is rolled back, tx2 will be able to insert the row and tx3 will generate the deadlock. Regards, Martin
[17 Mar 2014 20:03]
Sveta Smirnova
Thank you for the feedback. Yes, this is expected behavior for the deadlock: one transaction is able to insert a row and finish successfully, second rolled back. This is not a bug.
[17 Mar 2014 21:33]
Martin Arrieta
Agree with you that is the expected behavior, but check this part of the documentation: "The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions 2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When session 1 rolls back, it releases its exclusive lock on the row and the queued shared lock requests for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an exclusive lock for the row because of the shared lock held by the other." "At this point, sessions 2 and 3 deadlock" is not correct. only session 3 get the deadlock. Regards, Martin