Subject | Re: [firebird-support] Re: limbo transaction prevents user login |
---|---|
Author | Guido Klapperich |
Post date | 2005-08-23T08:25:08Z |
I wasn't aware that my english is so bad :-)
We use replication for more than three years, so we use 2 Phase Commit.
I would estimate, that one of ten replications fails, because the
connection gets interrupted. In that case the transaction in which the
replication was running is in limbo state, because it neither could be
commited nor rollbacked. So in the last years, we had a lot of limbo
transactions, but they never had been a problem.
But now it has been the first, that a limbo transaction causes a serious
problem. No user was able to log in to the database neither the user,
who started the replication nor any other user. They all get the error:
record from transaction 32141 is stuck in limbo.
Just to make it clear, I was able to solve the problem with gfix. But I
don't know, why the limbo transaction prevents every user from log in to
the database. That is my question and I hope, that someone can explain
it to me.
Regards
Guido
We use replication for more than three years, so we use 2 Phase Commit.
I would estimate, that one of ten replications fails, because the
connection gets interrupted. In that case the transaction in which the
replication was running is in limbo state, because it neither could be
commited nor rollbacked. So in the last years, we had a lot of limbo
transactions, but they never had been a problem.
But now it has been the first, that a limbo transaction causes a serious
problem. No user was able to log in to the database neither the user,
who started the replication nor any other user. They all get the error:
record from transaction 32141 is stuck in limbo.
Just to make it clear, I was able to solve the problem with gfix. But I
don't know, why the limbo transaction prevents every user from log in to
the database. That is my question and I hope, that someone can explain
it to me.
Regards
Guido