| Subject | RE: [firebird-support] What happened to opened transaction if the client is abnormally disconnected? |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2004-11-28T21:21:28Z |
At 01:59 AM 11/28/2004, Alan McDonald wrote:
commit. Unless you are using two phased commits and have the bad
luck to have your transaction die between the prepare phase and the
commit, your transactions will never go into limbo. That fortunate,
because the results of transactions in limbo can not be garbage
collected. (see more below).
When a client exits without saying goodbye, the server will eventually
probe the connection and discover that it's dead. The server then writes
a 10054 (10055?) message to the log and marks transactions associated
with the connection as rolled back. Eventually, some form of
garbage collection will remove any changes made by those transactions.
During the first connection to a database, the engine makes a pass
over the transaction inventory pages (well, the interesting subset
of them) and changes the state of active transactions to rolled back.
That catches any cases where the server somehow missed an ungraceful
exit.
(below) The purpose of two-phased commit is to synchronize transactions
on multiple databases so that if one commits, the other is guaranteed to
be able commit. The two phases are 'prepare' and 'commit'. During the
prepare phase, all data is written to the database, and all validation
and deferred work are performed. Once the transaction completes the
prepare phase, it can be committed - unless the database file itself
disappears, which is a problem handled in other ways. The only
difference between a prepare and a commit is the state of the two bits
that describe the transaction.
When the engine comes across a record whose transaction's state is limbo,
it knows that there is probably another database somewhere with related
data which may be committed, rolled back, or also in limbo. Until someone
matches this transaction with its mate(s) and determines what the outcome
should be, the records in limbo must stay.
Regards,
Ann
> >Limbo is a specific state that occurs in the middle of a two phase
> > If the client application abnormally disconnected (crashed), what
> > happened to the app's open transaction?
>
>this will result in a transaction in limbo - it has the same effect as a
>rollback but it leaves more garbage for you to clean up.
commit. Unless you are using two phased commits and have the bad
luck to have your transaction die between the prepare phase and the
commit, your transactions will never go into limbo. That fortunate,
because the results of transactions in limbo can not be garbage
collected. (see more below).
When a client exits without saying goodbye, the server will eventually
probe the connection and discover that it's dead. The server then writes
a 10054 (10055?) message to the log and marks transactions associated
with the connection as rolled back. Eventually, some form of
garbage collection will remove any changes made by those transactions.
During the first connection to a database, the engine makes a pass
over the transaction inventory pages (well, the interesting subset
of them) and changes the state of active transactions to rolled back.
That catches any cases where the server somehow missed an ungraceful
exit.
(below) The purpose of two-phased commit is to synchronize transactions
on multiple databases so that if one commits, the other is guaranteed to
be able commit. The two phases are 'prepare' and 'commit'. During the
prepare phase, all data is written to the database, and all validation
and deferred work are performed. Once the transaction completes the
prepare phase, it can be committed - unless the database file itself
disappears, which is a problem handled in other ways. The only
difference between a prepare and a commit is the state of the two bits
that describe the transaction.
When the engine comes across a record whose transaction's state is limbo,
it knows that there is probably another database somewhere with related
data which may be committed, rolled back, or also in limbo. Until someone
matches this transaction with its mate(s) and determines what the outcome
should be, the records in limbo must stay.
Regards,
Ann