Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 100 101 102 103 104 105 < 106 > 107 108 109 110 111 112 .. 218 >> Next


2-Phase Commit (2PC) Protocol

The functions of each interface are as follows:

Interface Description
API Used by the application for communication with the participant. The API performs tasks such as requesting 2PC sessions.
CPI Can be considered the 2PC protocol. The CPI handles the vote requests and the abort and commit messages.
PCI Manages the communications from the participant to the coordinator. These communications can include responses to requests for session information.

CICS and IMS act as coordinators, and in both systems the syncpoint manager coordinates the commit or rollback in all resources accessed in a logical unit of work.

CICS and IMS applications written using CLIv2 may establish multiple 2PC sessions with one or more Teradata RDBMS configurations.

Applications written using the preprocessor can establish only one session at a time. Assembler, Common Business Oriented Language (COBOL), Programming Language/1 (PL/I), and C are supported for CICS and IMS applications.

An application requests to participate in the 2PC protocol at the time the Teradata RDBMS session logs on. A CLI option can specify 2PC or non-2PC as the default startup mode.

Note: Multi-session applications may use a mix of 2PC and non-2PC sessions. Sessions running in non-2PC mode are unaffected by 2PC operation.

Phase 1 is the voting phase of the protocol; phase 2 consists of committing or aborting the changes.

Teradata RDBMS Database Administration

7 - 17 Chapter 7: Protecting Data

2-Phase Commit (2PC) Protocol

The processing scheme is illustrated below.

Phase1 Phase 2

time

FG11A003

For information on ... See .
Phase 1 processing following subsection
Phase 2 processing "2PC Processing - Phase 2" on page 7-21
In-doubt transaction "In-Doubt Transactions" on page 7-22 and "In-Doubt Resolution" on page 7-22
In-doubt participant

2PC Processing - Phase 1

At the start of each transaction, the initiating application generates a request for each prospective participant. Each participant is registered with the coordinator for the logical unit of work.

Upon receipt of the request, each participant determines if it can complete the transaction, then waits for instructions from the coordinator.

7 - 20

Teradata RDBMS Database Administration 7 - 17 Chapter 7: Protecting Data

2-Phase Commit (2PC) Protocol

IF the . THEN .
initiating application can make the update 1 The application generates a commit request for the transaction. 2 Upon detection of the commit request, the coordinator sends, via the client interface, a vote request message to all participants. 3 The participants report whether they can or cannot commit the change to their individual databases.
transaction can be completed participant votes to commit. Once a participant votes to commit, it cannot change its vote. Therefore, before voting, each participant saves enough information in the TJ to enable it to subsequently commit or rollback the change, even if it crashes after voting to commit.
transaction cannot be completed participant votes to reject. For example, if a participant's transaction failed before receiving the vote request, and the participant had already rolled the changes back, it would vote to reject.

2PC Processing - Phase 2

When the coordinator has received all votes, the transaction enters phase 2, in which the result of the vote is communicated to all participants.

The change can be committed only in phase 2. Based on the result of phase 1 voting, the coordinator sends a message to commit or abort to all participants.

IF . THEN the coordinator . AND THEN each participant .
all votes are to commit logs any pending updates, then sends a commit message to all participants 1 makes the appropriate changes and releases any locks. 2 returns its status to the coordinator following the commit.
there is at least one vote to abort, or if the coordinator is unable to communicate with at least one of the participants sends an abort message to all participants 1 aborts the operation and releases any locks held; no data is changed. 2 returns its status to the coordinator following the abort.

Teradata RDBMS Database Administration

7 - 17 Chapter 7: Protecting Data

2-Phase Commit (2PC) Protocol

In-Doubt Transactions

A transaction is in doubt if any of the participants are in doubt. An in-doubt transaction remains inactive until an abort or commit is received from the host application.

Once a transaction is in doubt, the only valid request is to terminate (by aborting or committing) the transaction.

A participant is in doubt:

From the time . Until the time .
the coordinator logs the vote of the participant the coordinator logs the confirmation of the participant of transaction termination.
from the time it votes to commit it receives and logs a response from the coordinator.

The coordinator considers the participant to be not in doubt once it has logged the confirmation of the participant of the completion of the unit of work. If a participant fails after phase 2 is initiated, that participant must perform the abort or commit processing after restart.
Previous << 1 .. 100 101 102 103 104 105 < 106 > 107 108 109 110 111 112 .. 218 >> Next