[
https://forge.continuent.org/jira/browse/SEQUOIA-1150?page=comments#action_15561
]
Emmanuel Cecchet commented on SEQUOIA-1150:
-------------------------------------------
The problem seems to only affect the single controller case (the distributed
controller case handles commit differently).
Try the following.
In
org.continuent.sequoia.controller.virtualdatasbase.VirtualDatabaseWorkerThread
line 2203.
Replace:
// Here, if the transaction isolation level was set to SERIALIZABLE, we
// need to broadcast the request to all controllers
if (!request.isAutoCommit()
&& requestFactory.isBroadcastRequired(transactionIsolation))
{
select.setMustBroadcast(true);
writeQueryExecutedInThisTransaction = true;
}
With:
// Here, if the transaction isolation level was set to SERIALIZABLE, we
// need to broadcast the request to all controllers
if (!request.isAutoCommit()
&& requestFactory.isBroadcastRequired(transactionIsolation))
select.setMustBroadcast(true);
if (select.isMustBroadcast())
writeQueryExecutedInThisTransaction = true;
Let me know if that fixes the problem.
> 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
> 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
