Illustration of multi-site update

You can set up a multi-site update that involves one coordinator and two participants.

The following figure shows an example of a multi-site update with one coordinator and two participants.

The following process describes each action that the figure illustrates.

Phase 1

1. When an application commits a logical unit of work, it signals the Db2 coordinator. The coordinator starts the commit process by sending messages to the participants to determine whether they can commit.
2. A participant (Participant 1) that is willing to let the logical unit of work be committed, and which has updated recoverable resources, writes a log record. It then sends a request-commit message to the coordinator and waits for the final decision (commit or roll back) from the coordinator. The logical unit of work at the participant is now in the prepared state.

   If a participant (Participant 2) has not updated recoverable resources, it sends a forget message to the coordinator, releases its locks, and forgets about the logical unit of work. A read-only participant writes no log records. The disposition (commit or rollback) of the logical unit of work is irrelevant to the participant.

   If a participant wants to have the logical unit of work rolled back, it writes a log record and sends a message to the coordinator. Because a message to roll back acts like a veto, the participant in this case knows that the logical unit of work is to be rolled back by the coordinator. The participant does not need any more information from the coordinator and therefore rolls back the logical unit of work, releases its locks, and forgets about the logical unit of work. (This case is not illustrated in the figure.)

Phase 2

1. After the coordinator receives request-commit or forget messages from all its participants, it starts the second phase of the commit process. If at least one of the responses is request-commit, the coordinator writes a log record and sends committed messages to all the participants who responded to the prepare message with request-commit. If neither the participants nor the coordinator have updated any recoverable resources, no second phase occurs, and no log records are written by the coordinator.
2. Each participant, after receiving a committed message, writes a log record, sends a response to the coordinator, and then commits the logical unit of work.

   If any participant responds with a roll back message, the coordinator writes a log record and sends a roll back message to all participants. Each participant, after receiving a roll back message writes a log record, sends an acknowledgment to the coordinator, and then rolls back the logical unit of work. (This case is not illustrated in the figure.)

3. The coordinator, after receiving the responses from all the participants that were sent a message in the second phase, writes an 'end' record and forgets the logical unit of work.