Subject | Re: [ib-support] Two-phase commits |
---|---|
Author | Ann W. Harrison |
Post date | 2001-12-14T18:02:51Z |
At 07:16 PM 12/14/2001 +0200, Salim Naufal wrote:
with some other event. In all likelihood, the other
event is a transaction in another database, though it could
be another transaction in the same database, or an external
event.
state on the TIP (transaction inventory page) has been set
to committed and the page has been written. The TIP is
written after all other pages affected by the transaction
have been written.
For a two-phase commit, the transaction state is set to
"prepared", all pages with changes are written, a log
record is written and then the TIP is written. At that
point, nothing can happen that will prevent the transaction
from being marked as committed, but it can still roll back.
When two or more transactions are coordinated, the client
requests each transaction to prepare itself. If any transaction
fails to prepare, all transactions are told to rollback.
If all transactions succeed in preparing, then all transactions
are told to commit. If some transaction fails catastrophically -
e.g. loses its connection with the client, gfix can use the
information in the log record to identify the other participants
in the coordinated transaction so the newly recovered transaction
can commit or rollback to match the others.
Regards,
Ann
>I remember that IB supports two-phase commits.A two phase commit allows a transaction to by synchronized
>What is this feature
with some other event. In all likelihood, the other
event is a transaction in another database, though it could
be another transaction in the same database, or an external
event.
>and how is it implemented.An InterBase transaction is committed when the transaction
state on the TIP (transaction inventory page) has been set
to committed and the page has been written. The TIP is
written after all other pages affected by the transaction
have been written.
For a two-phase commit, the transaction state is set to
"prepared", all pages with changes are written, a log
record is written and then the TIP is written. At that
point, nothing can happen that will prevent the transaction
from being marked as committed, but it can still roll back.
When two or more transactions are coordinated, the client
requests each transaction to prepare itself. If any transaction
fails to prepare, all transactions are told to rollback.
If all transactions succeed in preparing, then all transactions
are told to commit. If some transaction fails catastrophically -
e.g. loses its connection with the client, gfix can use the
information in the log record to identify the other participants
in the coordinated transaction so the newly recovered transaction
can commit or rollback to match the others.
Regards,
Ann