A commit operation is, by definition, an all-or-nothing affair. If a series of operations bound as a transaction cannot be completed, the rollback must restore the system (or cooperating systems) to the pre-transaction state.
In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.
When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)
Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.
The commit process proceeds as follows:
Phase 1
Each participating resource manager coordinates local operations and forces all log records out:
If successful, respond "OK"
If unsuccessful, either allow a time-out or respond "OOPS"
Phase 2
If all participants respond "OK":
Coordinator instructs participating resource managers to "COMMIT"
Participants complete operation writing the log record for the commit
Otherwise:
Coordinator instructs participating resource managers to "ROLLBACK"
Participants complete their respective local undos
In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.
In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.
When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)
Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.
The commit process proceeds as follows:
Phase 1
Each participating resource manager coordinates local operations and forces all log records out:
If successful, respond "OK"
If unsuccessful, either allow a time-out or respond "OOPS"
Phase 2
If all participants respond "OK":
Coordinator instructs participating resource managers to "COMMIT"
Participants complete operation writing the log record for the commit
Otherwise:
Coordinator instructs participating resource managers to "ROLLBACK"
Participants complete their respective local undos
In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
