Availability Guide for Application Design

Availability Through Process-Pairs and Monitors
Availability Guide for Application Design—525637-004
7-4
Operations That Are Not Retryable
gets fired by the backup process. If the missile was fired by the primary process, it is
no longer in the silo to be fired by the backup process.
Operations That Are Not Retryable
Operations that are not retryable include firing the next missile, printing a check, and
dispensing cash from an automated teller.
Clearly, to repeat one of these operations would be inappropriate if not disastrous.
Before the backup process fires the next missile, your application needs to know if the
primary process just fired a missile; otherwise, two missiles could get fired instead of
one. The backup process of your check-writing application needs to know whether the
primary process printed the most recently requested check; otherwise, two checks
could get written instead of one. Similarly, the backup process should not retry the
request to dispense $300 from the automated teller just to make sure that it happened.
For nonretryable operations, some attempt to synchronize the application with the
outside world should be made. You must either:
•
Roll back the effects of any operation that might have happened; for example, a
message could be sent to the appropriate authority to discard any checks printed
since a known point of consistency. All checks after that point could be printed
from the backup process.
•
Redesign the application in a way that makes the operation retryable; for example,
by identifying a specific missile to fire.
Otherwise, you must accept all the consequences.
How Do Process Pairs Work?
Whether you use the passive backup model or the active backup model, the underlying
principles of a process pair are the same. Figure 7-1 shows the generic model. The
following paragraphs introduce these generic principles.
A process pair consists of a primary process and a backup process that execute the
same object file in different processors.