Comments on: SELECT LOCK IN SHARE MODE and FOR UPDATE http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/ Everything about MySQL Performance Fri, 04 Jul 2008 15:12:49 +0000 http://wordpress.org/?v=2.5.1 By: Victor http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-286478 Victor Wed, 23 Apr 2008 12:38:03 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-286478 Problem solved with mysql 5.0.56. Problem solved with mysql 5.0.56.

]]> By: peter http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-286128 peter Wed, 23 Apr 2008 00:49:23 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-286128 Victor, I would suggest to try it with recent MySQL 5.0 version and if it still happens report it at bugs.mysql.com Victor,

I would suggest to try it with recent MySQL 5.0 version and if it still happens report it at bugs.mysql.com

]]> By: Victor http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284896 Victor Tue, 22 Apr 2008 06:40:09 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284896 Darseq> I have tested from two console boxes with mysql 5.0.21 on freebsd6 and linux. I also thought that update should succeed, but it does not! It waits for some table level locks which were made by second SELECT FOR UPDATE which in turn waits for X lock. That is why undetectable deadlock happens. But my opinion that that is a bug. Just try yourself (may be i missed something) - start 2 transactions from two consoles and make any SELECT FOR UPDATE for the SAME ROW in both transactions. Second transaction will wait for the lock, then from the first transaction try to UPDATE that row. In my case it blocks both transaction until timeout and it is very very strange! Can anyone explain me why? Or tell me that it is not working just for me because of my stupidness. Darseq> I have tested from two console boxes with mysql 5.0.21 on freebsd6 and linux. I also thought that update should succeed, but it does not! It waits for some table level locks which were made by second SELECT FOR UPDATE which in turn waits for X lock. That is why undetectable deadlock happens. But my opinion that that is a bug. Just try yourself (may be i missed something) - start 2 transactions from two consoles and make any SELECT FOR UPDATE for the SAME ROW in both transactions. Second transaction will wait for the lock, then from the first transaction try to UPDATE that row. In my case it blocks both transaction until timeout and it is very very strange! Can anyone explain me why? Or tell me that it is not working just for me because of my stupidness.

]]> By: darseq http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284632 darseq Mon, 21 Apr 2008 21:02:56 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284632 Interesting, but I think the update should actually succeed. Did you test with mysql.exe in two console (dos?) boxes? Using mysql ensures that you operate directly on the server with no other software layers in between. Also I find the syntax is_active=is_active rather odd. Always test using the most simple case. So do something like is_active='0' or so. I don't know about GET_LOCK/RELEASE_LOCK. p.s: did you know that a 'SELECT id into tmp from mf_banners where id=192 LOCK IN SHARE MODE' together with 'REPEATABLE_READ' suffices to get serializability? Interesting, but I think the update should actually succeed.
Did you test with mysql.exe in two console (dos?) boxes?
Using mysql ensures that you operate directly on the server
with no other software layers in between. Also I find the
syntax is_active=is_active rather odd. Always test using the
most simple case. So do something like is_active=’0′ or so.

I don’t know about GET_LOCK/RELEASE_LOCK.

p.s: did you know that a
‘SELECT id into tmp from mf_banners where id=192 LOCK IN SHARE MODE’
together with ‘REPEATABLE_READ’ suffices to get serializability?

]]> By: Victor http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284409 Victor Mon, 21 Apr 2008 13:11:32 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-284409 Following code cause an undetectable deadlock when run simultaneously. (Lock wait timeout exceeded;) START TRANSACTION; SELECT id into tmp from mf_banners where id=192 FOR UPDATE; UPDATE mf_banners set is_active=is_active where id=192; COMMIT; And I can't understand why. Transaction 1 takes X lock for record 192, then Transaction 2 try to take the same lock and can't, so T2 waits for X lock. Then T1 tries to update record (It holds X lock for that record) and it can't! Why??? I have serialized access with GET_LOCK and RELEASE_LOCK and that helped to avoid lock wait timeouts, but i'am not sure that they are replication safe. Are they replication safe, especially when used inside stored procedures? Thank you for help. Following code cause an undetectable deadlock when run simultaneously. (Lock wait timeout exceeded;)
START TRANSACTION;
SELECT id into tmp from mf_banners where id=192 FOR UPDATE;
UPDATE mf_banners set is_active=is_active where id=192;
COMMIT;

And I can’t understand why.
Transaction 1 takes X lock for record 192, then Transaction 2 try to take the same lock and can’t, so T2 waits for X lock. Then T1 tries to update record (It holds X lock for that record) and it can’t! Why???
I have serialized access with GET_LOCK and RELEASE_LOCK and that helped to avoid lock wait timeouts, but i’am not sure that they are replication safe. Are they replication safe, especially when used inside stored procedures?
Thank you for help.

]]> By: darseq http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253941 darseq Tue, 18 Mar 2008 11:54:18 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253941 Oh yeah, and before I forget: A lock only becomes active when the statement is actually EXECUTED, so a PREPARE does not necessarily lock until the point of actually EXECUTING the statement. Oh yeah, and before I forget: A lock only becomes active when
the statement is actually EXECUTED, so a PREPARE does not
necessarily lock until the point of actually EXECUTING the
statement.

]]> By: darseq http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253940 darseq Tue, 18 Mar 2008 11:47:40 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253940 Hi Pratab, Check the following: - Is the transaction isolation level properly set? For ODBC use the ODBC API and something like: SQLSetConnectAttr(dbc_h, SQL_ATTR_TXN_ISOLATION, (SQLPOINTER) isolation, SQL_IS_INTEGER); - Is AUTOCOMMIT set to false? For ODBC use the ODBC API and something like: SQLSetConnectAttr(dbc_h, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)autocommit, SQL_IS_UINTEGER); - When using ODBC you do not need to specify BEGIN statements. A new transaction start automatically after the previous transaction commits. To commit a transaction in ODBC, use the API: SQLEndTran(SQL_HANDLE_DBC,dbc_h,SQL_COMMIT); If you choose to use a 'sql passthrough' COMMIT statement however, the ODBC driver itself may not know about your transaction ending and may not automatically start a new one so beware of this. Hi Pratab,

Check the following:

- Is the transaction isolation level properly set?
For ODBC use the ODBC API and something like:
SQLSetConnectAttr(dbc_h,
SQL_ATTR_TXN_ISOLATION,
(SQLPOINTER) isolation,
SQL_IS_INTEGER);

- Is AUTOCOMMIT set to false?
For ODBC use the ODBC API and something like:
SQLSetConnectAttr(dbc_h,
SQL_ATTR_AUTOCOMMIT,
(SQLPOINTER)autocommit,
SQL_IS_UINTEGER);

- When using ODBC you do not need to specify BEGIN statements. A new transaction start automatically
after the previous transaction commits.
To commit a transaction in ODBC, use the API:
SQLEndTran(SQL_HANDLE_DBC,dbc_h,SQL_COMMIT);
If you choose to use a ’sql passthrough’ COMMIT
statement however, the ODBC driver itself may not
know about your transaction ending and may not
automatically start a new one so beware of this.

]]> By: peter http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253627 peter Mon, 17 Mar 2008 15:26:27 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253627 Pratap, you would do better of asking question on forum and providing complete SQL example. Most typical the problem is you do not have transaction open. Pratap, you would do better of asking question on forum and providing complete SQL example.

Most typical the problem is you do not have transaction open.

]]> By: pratap http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253562 pratap Mon, 17 Mar 2008 08:17:37 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-253562 In an ODBC based application, I need to lock a row while selecting it. For this I did use SELECT FOR UPDATE in SQLPREPARE() odbc primitive. But it is not working. WHat may be the reason, Ia m working on Linux. In an ODBC based application, I need to lock a row while selecting it. For this
I did use SELECT FOR UPDATE in SQLPREPARE() odbc primitive. But it is not working.
WHat may be the reason, Ia m working on Linux.

]]> By: pavel http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-223115 pavel Mon, 24 Dec 2007 20:47:46 +0000 http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/#comment-223115 DO NOT EVER DO THIS: update SOMETABLE as fn set fn.counter = (select count(*) from SOMEOTHERTABLE as p where p.X = fn.X LOCK IN share mode); Good luck with your locked mysql DO NOT EVER DO THIS:

update SOMETABLE as fn set fn.counter = (select count(*) from SOMEOTHERTABLE as p where p.X = fn.X LOCK IN share mode);

Good luck with your locked mysql

]]>