SELECT ... FOR UPDATE with no actual UPDATE prevents backend recovery
----------------------------------------------------------------------
Key: SEQUOIA-1150
URL: https://forge.continuent.org/jira/browse/SEQUOIA-1150
Project: Sequoia
Type: Bug
Components: Recovery Log
Versions: sequoia 2.10.10
Environment: Discovered on Centos 5 with MySQL 5.1 for backends and Controller
Reporter: Joel Kozikowski
Priority: Critical
If the following sequence is issued to the database:
1) Start transaction
2) SELECT * WHERE ID = 1234 FOR UPDATE
3) End transaction
4) <zero or more other queries>
5) Start transaction
6) SELECT * WHERE ID = 1234 FOR UPDATE
7) End transaction
The following gets written to the recovery log:
1) BEGIN (transaction n)
2) SELECT * WHERE ID = 1234 FOR UPDATE (transaction n)
3) BEGIN (transaction n+1)
4) SELECT * WHERE ID = 1234 FOR UPDATE (transaction n+1)
The absense of a "COMMIT" in the recovery log causes ""Lock wait timeout
exceeded; try restarting transaction"
in MySQL when played back (because two seprate transactions are trying to lock
the same record, but never release the locks).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Sequoia mailing list
Sequoia@lists.forge.continuent.org
http://forge.continuent.org/mailman/listinfo/sequoia
