2. Distributed Transaction Processing Using XA
MySQL version 5.0 lets you coordinate transactions involving different resources
by using the X/Open Distributed Transaction Processing model
XA. Although currently not very widely used, XA offers
attractive opportunities for coordinating all kinds of resources with
transactions.
In version 5.0, the server uses XA internally to coordinate the
binary log and the storage engines.
A set of commands allows the client to take advantage of XA
synchronization as well. XA allows different statements entered by
different users to be treated as a single transaction. On the other
hand, it imposes some overhead, so some administrators turn it off
globally.
XA includes a transaction manager that coordinates
a set of resource managers so that they
commit a global transaction as an atomic unit. Each transaction is
assigned a unique XID, which is used by the transaction manager and the
resource managers. When used internally in the MySQL server, the
transaction manager is usually the binary log and the resource managers
are the storage engines. The process of committing an XA transaction is
shown in Figure 3 and
consists of two phases.
In phase 1, each storage engine is asked to prepare for a commit.
When preparing, the storage engine writes any information it needs to
commit correctly to safe storage and then returns an OK message. If any
storage engine replies negatively—meaning that it cannot commit the
transaction—the commit is aborted and all engines are instructed to roll
back the transaction.
After all storage engines have reported that they have prepared
without error, and before phase 2 begins, the transaction cache is
written to the binary log. In contrast to normal transactions, which are
terminated with a normal Query event
with a COMMIT, an XA transaction is
terminated with an Xid event containing
the XID.
In phase 2, all the storage engines that were prepared in phase 1
are asked to commit the transaction. When committing, each storage
engine will report that it has committed the transaction in stable
storage. It is important to understand that the commit cannot fail: once
phase 1 has passed, the storage engine has guaranteed that the
transaction can be committed and therefore is not allowed to report
failure in phase 2. A hardware failure can, of course, cause a crash,
but since the storage engines have stored the information in durable
storage, they will be able to recover properly when the server restarts.
After phase 2, the transaction manager is given a chance to
discard any shared resources, should it choose to. The binary log does
not need to do any such cleanup actions, so it does not do anything
special with regard to XA at this step.
In the event that a crash occurs while committing an XA
transaction, the recovery procedure in Figure 4 will take place when the server
is restarted. At startup, the server will open the last binary log and
check the Format description
event. If the binlog-in-use
flag described earlier is set, it indicates that the server
crashed and XA recovery has to be executed.
The server starts by walking through the binary log that was just
opened and finding the XIDs of all transactions in the binary log by
reading the Xid events. Each storage
engine loaded into the server will then be asked to commit the
transactions in this list. For each XID in the list, the storage engine
will determine whether a transaction with that XID is prepared but not
committed, and commit it if that is the case. If the storage engine has
prepared a transaction with an XID that is not in
this list, the XID obviously did not make it to the binary log before
the server crashed, so the transaction should be rolled back.
