Availability Guide for Application Design
Designing Applications for Change
Availability Guide for Application Design—525637-004
10-25
Using the Trickle Catchup Approach
Upgrading a NonStop Tuxedo Service
In NonStop Tuxedo applications, you can upgrade a service without any interruption to
client processes. It is possible to do this because the same service can be supplied by
more than one Tuxedo server and each Tuxedo server is configured as a separate
NonStop TS/MP server class.
Client processes invoke servers using a service name. The Tuxedo server that takes
the request can be any one of several servers that provide that service. After new
versions of servers are added, a client request might receive service from either the old
version or the new version of the server until the old versions are deleted.
If you do not already have a second server class offering the service, you can upgrade
a service using NonStop Tuxedo configuration tools as follows:
1. Build the upgraded service into the new Tuxedo server, move the new server to the
production environment, and add the new server to the running configuration.
2. Boot the server entry so that it advertises the new and improved service.
3. Suspend the service in the original server class.
If you already have two or more Tuxedo servers offering the service, you can simply
overwrite the service object code and use the NonStop Tuxedo tools to shutdown and
boot each Tuxedo server in turn.
Dual-Server Approach
In the dual-server approach, the new version of the server is installed as a separate
server class. Upgrading the server involves the following steps:
1. Install the upgraded server as a new server class.
2. Freeze the existing server class.
The client (or requester) must contain logic that attempts to resend messages to the
alternate server class if an attempt to send to the existing server class fails with a
server frozen error.
Using the Trickle Catchup Approach
As discussed in Section 4, Data Protection and Recovery, the trickle catchup design
model can be used to allow a client or requester process to continue to run while the
server process is unavailable. By posting messages to a queue file instead of sending
them to the server, the requester is able to continue functioning. When the server
comes back online, it can read the messages from the queue and process them before
reading any new messages from the client.
For applications that can tolerate a temporary delay in request processing, the trickle
catchup design can be used to allow dynamic upgrade of the server process. This
design is typically used where the order in which requests are processed is important.