Hi Andrew,
this is with Sequoia 2.10.10, on a single non-distributed controller
with 2 backends - both emebedded derby databases.
This might be an issue related to the non-distributed code. Could you
add a <Distributed> element to your configuration file and have another
run just to check if the order in the recovery log changes.
If the problem persists, it would be interesting to have a trace of the
log with virtualdatabase and recoverylog loggers set to DEBUG in
log4j.properties to see in what order events occur in your scenario.
Thanks a lot for the feedback,
Emmanuel
a set of sample recovery log entries are:
Log_id 103: Transaction_id = 146, RequestId = 0, SqlStmt = begin
Log_id 104: Transaction_id = 146, RequestId = 322, SqlStmt = update users set
lastlogin = {ts '2008-06-26 17:27:37.0'} where id = ?
Log_id 105: Transaction_id = 147, RequestId = 0, SqlStmt = begin
Log_id 106: Transaction_id = 147, RequestId = 326, SqlStmt = update users set
lastlogin = {ts '2008-06-26 17:27:37.0'} where id = ?
Log_id 107: Transaction_id = 148, RequestId = 0, SqlStmt = begin
Log_id 108: Transaction_id = 148, RequestId = 328, SqlStmt = update users set
lastlogin = {ts '2008-06-26 17:27:37.0'} where id = ?
Log_id 109: Transaction_id = 149, RequestId = 0, SqlStmt = begin
Log_id 110: Transaction_id = 149, RequestId = 330, SqlStmt = update users set
lastlogin = {ts '2008-06-26 17:27:37.0'} where id = ?
<a few more of these>
Log_id 123: Transaction_id = 146, RequestId = 0, SqlStmt = commit
Log_id 124: Transaction_id = 147, RequestId = 0, SqlStmt = commit
Log_id 125: Transaction_id = 148, RequestId = 0, SqlStmt = commit
Log_id 126: Transaction_id = 149, RequestId = 0, SqlStmt = commit
<a few more commits>
Many thanks for any help,
Andy
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Cecchet
Sent: 26 June 2008 16:33
To: Sequoia general mailing list
Subject: Re: [Sequoia] Deadlock when replaying recovery log
Hi Andrew,
I'm having problems with replaying recovery logs, where the replay
appears to be deadlocking itself. I'm getting the following error:
2008-06-26 09:53:30,103 ERROR
org.continuent.sequoia.controller.recoverylog.RecoverThread - Recovery
process failed to replay transaction 1110: request
StatementExecuteUpdateTask from transaction 1110 (update... ) (Backend
AndyCluster - BackendWorkerThread for backend 'DB-BACKUP' with RAIDb
level:1 failed (A lock could not be obtained within the time requested.
As an example, consider the following simplified scenario:
I have a table 'test':
create table test ( a int , b int )
insert into test values ( 1, 1 )
we then have two transactions, t1 & t2 each in different threads which
do the following:
1) t1: update test set b = 2 where a = 1
2) t2: update test set b = 3 where a = 1
3) t1: commit
4) t2: commit
normally, this will work fine, when t2 executes, it is blocked on a
lock, but as soon as t1 commits, the lock is freed and t2 then commits.
however, if you replay the transaction log, all the statements are
executed sequentially, and what I think is happening is that the 2nd
statement hangs and eventually has a lock timeout, as t1 will not be
commited until after it.
This means that you can't recover, as you can't replay the log.
Is my understanding correct, and if so, is there anything I can do
about this?
There is something wrong here because the recovery log stores queries in the
execution order and not in their arrival order.
This means that the scenario you are describing should not be logged this way
in the recovery log.
Could you provide a dump of your recovery log content?
Which version of Sequoia are you using?
Are all your database backends running the same database engine?
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
