[
https://forge.continuent.org/jira/browse/SEQUOIA-1150?page=comments#action_15567
]
Emmanuel Cecchet commented on SEQUOIA-1150:
-------------------------------------------
The LogCommitEvent code already takes care of read-only transactions, there is
no need to do that in logCommit.
Replace:
public long logCommit(TransactionMetaData tm)
{
if (tm.isReadOnly())
{
// don't log commit, if trx is read only
return 0;
}
else
{
long id = incrementLogTableId();
loggerThread.log(new LogCommitEvent(new LogEntry(id, tm.getLogin(),
COMMIT, null, LogEntry.TRANSACTION, tm.getTransactionId())));
tm.setLogId(id);
return id;
}
}
with
public long logCommit(TransactionMetaData tm)
{
long id = incrementLogTableId();
loggerThread.log(new LogCommitEvent(new LogEntry(id, tm.getLogin(),
COMMIT, null, LogEntry.TRANSACTION, tm.getTransactionId())));
tm.setLogId(id);
return id;
}
Keep me posted if that fixes the issue.
> 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
