Guardian Programmer's Guide

Writing a Requester Program
Guardian Programmer’s Guide — 421922-014
21 - 7
File Sync Block Checkpoints (Example)
File Sync Block Checkpoints (Example)
Assume that a requester is a process pair. The process pair opens a disk file or a
process with sync depth value of 3. This causes the server to allocate three status
blocks for the saved results with the opener control block.
In its main loop, the requester performs a single CHECKPOINT call, including the file
sync block. The call to CHECKPOINT is followed by three WRITE operations on the
file. This is repeated for each iteration of the loop in the requester. The server saves
the results of the WRITE operations in its three consecutive status blocks. Note that if
the requester issues a fourth WRITE operation without an intervening file sync block
checkpoint, the server no longer retains information about the first WRITE operation
(the requester is violating its sync depth). The server cannot detect this error during
normal processing. The error is detected only if the requester fails while performing its
fourth WRITE operation, because the sync ID of the first WRITE operation is too old for
a retry.
If the requester’s primary process fails, the backup process takes over at the most
current checkpoint, which is just before the three WRITE operations, no matter where
the primary process actually was executing at the time of the failure. The backup
process becomes the primary process. As the process reiterates up to and past the
actual point of failure it might redo all or none of these WRITEs. The server might
receive duplicate requests. There are four possible outcomes:
•
No WRITE operations were processed by the primary process. In this case, no
duplicates are detected by the server. Processing continues normally.
•
WRITE 1 was processed by the primary process. The server recognizes the
duplicate request. (Its last sync ID is that of the first WRITE executed by the
primary process before it failed.) The result is returned without reexcuting the
WRITE operation in the server. When the new primary process executes WRITE 2,
it becomes a new request and it is processed normally by the server. The same is
true for WRITE 3.
•
WRITEs 1 and 2 were processed by the primary process. These WRITE
operations are recognized and handled as duplicates. WRITE 3 becomes a new
request.
•
All three WRITE operations were successfully processed by the primary process
before the failure occurred. The new primary process gets the saved responses
from the server. On the next iteration of the main loop, the sync ID values tell the
server that these are new requests.
Thus, the server process ensures that any failure in the requester does not result in
WRITE operations being executed more than once by the server.
I/O Synchronization in Requester
Normally, there are minimal synchronization requirements on the requester side, as
long as the requester is not a process pair. As a rule of thumb, set the values for
nowait-depth and sync-depth as follows: