RDF System Management Manual for H-Series RVUs (RDF 1.8)

Assume that the primary system \B goes down after having transmitted the commit record for
T13 to its backup system \Y. At that point \Y has the commits for T10, T13, T20, T21, T22 and
T36. \Y only has to perform local undo (during which T12 is undone).
The purger on \X (the network master) determines that the first transaction requiring network
undo is T12 because that transaction was active on both \A and \B when \B went down.
Therefore, even though T12 originated on \A and was committed on \A, it must be undone on
\X (the backup system of \A) because it was undone on \Y (the backup system of \B). This
ensures database consistency across both nodes. When the purger identifies the first network
transaction that must be undone during network undo processing, it logs an RDF 877 event
message specifying that transaction.
Besides transaction T12, transactions T14 and T15 must also be undone on \X because they
followed the commit of T12 on \A and their database changes could have been based on the
committed outcome of T12. If T14 and T15 are not also undone, database consistency could be
compromised because their effects on the database might have been based upon data that was
backed out. T14 is a local transaction, not a network transaction. Nonetheless, its database changes
could have been based on the outcome of T12 and therefore must be undone. Thus, both network
and business consistency are maintained.
T13 does not, however, have to be undone even though it committed on \A after T12. Why?
Because the purger on \X (the network master) determines that, although T13 followed T12 on
\A, the sequence for these two commits had to have been reversed on \B, where the commit for
T13 preceded the commit for T12. Therefore, the purger determines that these two transactions
could not have touched the same data, and T13 does not need to be undone.
This illustrates a very important point. With network transactions, the commit sequence of
network transactions might differ from one node to another, depending on where the transactions
originated. For example, consider two network transactions: T101 and T102. Assume T101
originated on \M and T102 originated on \N. Assume further that they altered data on both \M
and \N, and committed at the same time. The commit operation for T101 is coordinated by the
TMP on \M because that is where T101 originated; similarly, T102 is coordinated by the TMP
on \N because that is where T102 originated. Thus, on \M, the sequence of commit records on
the audit trail will likely be T101 followed by T102, whereas on \N it will likely be T102 followed
by T101.
For these two reasons, we can be certain T101 and T102 did not alter the same data:
• Transaction record locking would have prevented these transactions from altering the same
data.
• The commit sequence on \M being T101 followed by T102 and the commit sequence on \N
being T102 followed by T101 unequivocally means that these two transactions were active
at the same time and committed at the same time. Therefore they could not have altered the
same data.
If we return to the issue of T13 in the example further above, the commit sequence differs on \A
and \B. When the purger on \A determines that T12, T14, and T15 must be undone, it also
determines that the results of T13 can be kept intact because T13 had to have completed on \B
before T12. Why? The commit records on \A guarantee that both T12 and T13 did indeed commit.
Therefore, although the commit record for T12 is missing from \B, the commit record for T13 is
present. This guarantees that T13 committed prior to T12, and that the results of T13 can be kept
intact on both nodes.
When a purger determines that it can keep the results of a transaction even though that transaction
follows one that must be undone because data for it is missing elsewhere, the purger logs an
RDF 823 event message identifying the particular transaction.
282 Network Transactions