Comments on: InnoDB not releasing a row lock? http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/ Everything In Life Is Random! (Personal and Work) Sat, 19 May 2012 00:06:06 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Locked rows in mediawiki-db « Logbuffer-Blog http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-10302 Locked rows in mediawiki-db « Logbuffer-Blog Tue, 29 Jun 2010 13:21:54 +0000 http://venublog.com/?p=284#comment-10302 [...] Venu Anuganti wrote about an odd locking-problem with MySQLs InnoDB-Engine which I verified on a [...] [...] Venu Anuganti wrote about an odd locking-problem with MySQLs InnoDB-Engine which I verified on a [...]

]]> By: Heikki Tuuri http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-3836 Heikki Tuuri Mon, 19 May 2008 15:04:47 +0000 http://venublog.com/?p=284#comment-3836 Venu, thank you for noticing this. I replied in the forum: on the REPEATABLE READ level, the user who has executed INSERT ... and received a duplicate key error, now knows that a duplicate exists. It makes sense to keep the lock on the duplicate, as then the execution is serializable for the user who received the duplicate key error. REPEATABLE READ in InnoDB is a serializable level, except for consistent read SELECTs. On the READ COMMITTED level, I do not see any reason for InnoDB to keep the lock on the duplicate. It would make sense to release it. I have now filed: http://bugs.mysql.com/bug.php?id=36801 Best regards, Heikki Venu,

thank you for noticing this. I replied in the forum:

on the REPEATABLE READ level, the user who has executed INSERT … and received a duplicate key error, now knows that a duplicate exists. It makes sense to keep the lock on the duplicate, as then the execution is serializable for the user who received the duplicate key error. REPEATABLE READ in InnoDB is a serializable level, except for consistent read SELECTs.

On the READ COMMITTED level, I do not see any reason for InnoDB to keep the lock on the duplicate. It would make sense to release it.

I have now filed:
http://bugs.mysql.com/bug.php?id=36801

Best regards,

Heikki

]]> By: rosetee http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-3238 rosetee Thu, 08 May 2008 23:27:39 +0000 http://venublog.com/?p=284#comment-3238 I would say it is a bug if you are in autocommit mode. If you are using transaction mode it is trivial whether the DB releases the lock or not before the txn is either rolledback or commited. I would say it is a bug if you are in autocommit mode. If you are using transaction mode it is trivial whether the DB releases the lock or not before the txn is either rolledback or commited.

]]> By: rosetee http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-3237 rosetee Thu, 08 May 2008 23:26:36 +0000 http://venublog.com/?p=284#comment-3237 I would say it is a bug if you are in autocommit mode. If you are using transaction mode it is trivial whether the DB releases the lock or not before the txn is either or commited. I would say it is a bug if you are in autocommit mode. If you are using transaction mode it is trivial whether the DB releases the lock or not before the txn is either or commited.

]]> By: Eric Bergen http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-2937 Eric Bergen Mon, 05 May 2008 21:37:13 +0000 http://venublog.com/?p=284#comment-2937 Locking in innodb is such that innodb doesn't know which statements set a lock, only which transactions. Since the transaction isn't rolled back locks associated with it will still be valid until it's either rolled back or committed. Locking in innodb is such that innodb doesn’t know which statements set a lock, only which transactions. Since the transaction isn’t rolled back locks associated with it will still be valid until it’s either rolled back or committed.

]]> By: Venu Anuganti http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-2922 Venu Anuganti Mon, 05 May 2008 18:02:17 +0000 http://venublog.com/?p=284#comment-2922 The problem is even on READ COMMITTED I get blocked; It can be relaxed for REPEATABLE READ The problem is even on READ COMMITTED I get blocked; It can be relaxed for REPEATABLE READ

]]> By: Venu Anuganti http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-2921 Venu Anuganti Mon, 05 May 2008 17:52:11 +0000 http://venublog.com/?p=284#comment-2921 The doc says "A duplicate-key error rolls back the SQL statement, if you have not specified the IGNORE option in your statement. "; but apparently thats not the case. The doc says “A duplicate-key error rolls back the SQL statement, if you have not specified the IGNORE option in your statement. “; but apparently thats not the case.

]]> By: Eric Bergen http://venublog.com/2008/05/05/innodb-not-releasing-a-row-lock/comment-page-1/#comment-2920 Eric Bergen Mon, 05 May 2008 17:41:37 +0000 http://venublog.com/?p=284#comment-2920 It's a feature of innodb to roll back the statement that caused the error and not the entire transaction in some cases. Things like deadlocks will rollback the entire transaction but duplicate key and other errors that are detected in the sql layer will only rollback the current transaction. There are some details here http://dev.mysql.com/doc/refman/5.0/en/innodb-error-handling.html It’s a feature of innodb to roll back the statement that caused the error and not the entire transaction in some cases. Things like deadlocks will rollback the entire transaction but duplicate key and other errors that are detected in the sql layer will only rollback the current transaction.

There are some details here http://dev.mysql.com/doc/refman/5.0/en/innodb-error-handling.html

]]>