Distributed Transactions - Transaction Processing - page 302

For example, in the case of the distributed transaction of Example 13.1 ,the
update on relation r must either be accomplished and persist at all the servers s i ,
i D 0;:::;k, or be rolled back at all these servers.
To ensure global atomicity, a subtransaction of a distributed transaction can be
allowed to commit only if we are sure that all the other subtransactions can also
be committed. Even if a subtransaction had successfully completed all the database
actions it was requested to do, it cannot unilaterally to decide to commit. This is
because some other subtransaction may still fail and abort or has done so already. If
some subtransaction aborts, then all the other subtransactions must abort, too.
We also note that a subtransaction cannot tell whether or not it has completed all
the actions it is expected to do, until the coordinator tells it so. Thus, after perform-
ing a requested action, the subtransaction must wait for the next request, which may
be a request for a new database action or a request to abort or to prepare to commit .
Only if all the subtransactions are prepared to commit, can all of them commit.
When the application process requests to commit a distributed transaction, the
coordinator performs an atomic commit protocol in order to find out whether or not
the transaction can be committed, that is, whether or not all its subtransactions are
prepared to commit, and if so, to tell the participants to commit their subtransactions.
We say that a forward-rolling subtransaction T i of a distributed transaction is a
prepared-to-commit transaction or a transaction in the prepared-to-commit state, if
it has written a special prepare-to-commit log record and forced the log onto disk.
In the active-transaction table, the prepared-to-commit state of T i is represented as

state .T i / D “prepared-to-commit.”

Both commit and rollback must be made possible for every prepared-to-commit
subtransaction. When the requirements imposed by the basic ARIES algorithm are
satisfied, so that, among other things, all transactions run at isolation level 1 or
higher, we know that it is possible to abort and roll back any forward-rolling
transaction (assuming, of course, that there exist sufficient computational and
storage resources for the execution of the undo actions). That also commit is
possible for a prepared-to-commit transaction may not be immediately obvious,
because the system may have to abort and roll back transactions due to a deadlock.
With lock-based concurrency control, a transaction involved in a deadlock may have
to be aborted and rolled back. But such a transaction is waiting for a lock and hence
has not yet performed all its database actions; thus, it cannot be a prepared-to-
commit transaction. By similar reasoning, with optimistic concurrency control, a
transaction that is aborted and rolled back due to an action coming too late cannot
be a prepared-to-commit transaction.

13.4 Two-Phase Commit Protocol

The most common atomic commit protocol in use is called the two-phase commit
protocol ,or 2PC , for short. This protocol comes in several variants, of which we