[ https://forge.continuent.org/jira/browse/SEQUOIA-1150?page=comments#action_15570 ]
Joel Kozikowski commented on SEQUOIA-1150: ------------------------------------------ More info: actually, I think I may have mispoken slightly. The "COMMIT only" entries I believe were a result of a "being transaction" followed by any query that was truely a query with no "FOR UPDATE" statement, followed by an "end transaction" In studying the Sequoia code, I believe that is due to the fact that the "BEGING" is written out in a lazy fasion (i.e. it is held until the first INSERT, UPDATE, or SELECT ... FOR UPDATE" is issued. Starting and ending a transaction with no modifications in between is fairly common in a Spring based service. The call into the service starts a transaction, and the exiting from the service call ends a transaction. > 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 > Single controller configuration > Reporter: Joel Kozikowski > Assignee: Emmanuel Cecchet > Priority: Critical > Attachments: TestSequoiaSelectForUpdate.java > > > 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
