Availability Guide for Application Design

Data Protection and Recovery
Availability Guide for Application Design—525637-004
4-23
Trickle Catchup
Trickle Catchup
When the order in which requests are executed is important, you can use a similar
technique sometimes known as “trickle catchup.” As with the transaction playback
example, this approach can be successful in applications that can get by for a short
period without immediate response to the user. Figure 4-7 on page 4-23 shows the
design.
During normal operation, the client process sends requests to the server process for
processing. If the server becomes unavailable, the client enqueues each request on
the queue file.
When the server becomes available again, the server reads and processes the records
from the queue file first. When the queue file is empty, it resumes reception of requests
directly from the front-end process.
To make this approach work, the client process is responsible for determining when to
send requests directly to the server and when to send them to the queue file. During
normal operation, the client process simply sends requests to the server and
recognizes that the server is down when its send operation is rejected. When the
server is brought back online, however, the front-end process must determine when
the server has emptied the queue of requests before resuming transmission of
requests directly to the server.
Figure 4-7. Queue Files and Trickle Catchup
Application
Data
Queue File
Audit Trail
Server
System
Client
System
Normal
Information
Flow
Alternate
Information
Flow
Client
Process
Server
VST307.vdd