Most of the information in this section is applicable only to Multiple Resilience Configurations, and to a lesser extent to the Local Database Resilience Client. For all other configurations the only part of this section that is at all relevant is that relating to the Network Status table, as you can use to check how DP4 is configured. Most of the pages in this section start with This page applies to ... to indicate which configurations they apply to.
The Resilience API is primarily based on using two special tables on the database. Reading and updating these tables allows you to find out about and control the servers your application is using.
The Network Layout table (@NETWORK) specifies which server or servers are to be used for the database or for individual tables on it. It is only used with multiple resilience.
The Network Status Table (@NET_STATUS) table can be interrogated to discover what resilience configuration (if any) is in effect and whether servers are on- or off-line. It can be updated to force servers on- or off-line. This table is available in any DP4 configuration, though its use will vary according to the configuration.
When the resilience software is loaded, operations on these tables do not access data on the database, but instead manipulate control information held in the memory of the resilience programs. Updates to these table take effect immediately, without a wait until the next db_commit() or db_checkpoint() . This makes it possible to change servers within a commit unit, and create transactions distributed across multiple servers. See Operation of @Network with Multiple Resilience Loaded for details.
Because the @NETWORK and @NET_STATUS tables appear to be ordinary database tables, they can be manipulated by programs written in C or DP4 QA Build, or by utilities such as BROWSER.
A global
variable, broken, can also be used to test network status.
A second technique, fully available only to the C/C++ programmer, allows access to be switched from the local to the remote server(s) and back again, by adding a special value, LOCN_OVERRIDE to the flags in fetch and update operations.
When a muliple resilience configuration is in use there are some important changes to DP4 functionality. In particular the operation of secondary indexes and commits may be affected. This is discussed in more detail in Multiple Resilience Implementation.