[
https://forge.continuent.org/jira/browse/SEQUOIA-1150?page=comments#action_15571
]
Emmanuel Cecchet commented on SEQUOIA-1150:
-------------------------------------------
The LogCommitEvent code remove the transaction from the log if it is empty.
Otherwise it logs the commit. I don't see how you can only get a COMMIT in the
log with that patch. If you have a BEGIN/SELECT in the log, the commit should
be logged \\.
To force the transaction to be considered as a write transaction, in
RequestManager.statementExecuteQuery() line 553, add a call to
tm.setReadOnly(false) as follows:
if (request.isMustBroadcast() && tm.isReadOnly())
{
/*
* If the transaction still shows as read-only, begin has not been
* logged yet and we need to lazily log this transaction start (see
* SEQUOIA-1063) -- Note: If this code is invoked from
* DistributedStatementExecuteQuery, begin will already be logged (in
* DistributedRequestManager.lazyTransactionStart) and the transaction
* marker will not be set anymore to read-only which will prevent us
* from logging twice in the distributed case.
*/
request.setIsLazyTransactionStart(true);
--> tm.setReadOnly(false);
}
> 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
[email protected]
http://forge.continuent.org/mailman/listinfo/sequoia
