The information in this section applies only to Multiple Resilience Configurations, and to a lesser extent, to Local Database Resilience Configurations. It explains some of the changes to the operation of DP4 when Resilience is in effect.
The information on database Reads applies only to Multiple Resilience Configurations.
All records read via AUXDISTR are returned to the user with a zero timestamp. This has the effect of making it impossible to update a record updated by another user since the start of the reading programs transaction. This can result in commit failures that would not arise in a standalone or simple client/server configuration. For details of this effect see Effect of Networking on Commit Failures.
If a table is set to be accessed on more than one server AUXDISTR will normally only read any particular record from one server. However, there are two situations where internally the record is in fact read from multiple servers:
The details of how AUXDISTR selects the server to read from when the read only needs to go to one server depend on the release of AUXDISTR in use:
Up to release 4.620 AUXDISTR selects a server at random on every read where more than one server could be used. This can cause problems with secondary indexes even if the secondary index is unique. This problem is described in AUXDISTR and Secondary Indexes. AUXDISTR tries to remedy this defect using the "Block Fetch Optimisation", but this is not totally effective. Up to release 4.620 secondary indexes are unreliable where a table can be accessed on more than one server. In fact patch releases of AUXDISTR for 4.619 and 4.620 are available which work like the 4.621 release described next.
From release 4.621 and in patch releases of 4.523/4.619 dated 11 July 2003 or later, AUXDISTR works in quite a different way:
If one of the servers in the list is the local server (i.e. it matches a value specified in the -server command tail to AUXDISTR), that server is always used to access the table.
Otherwise, each table area in a calling program is assigned to a fixed server at random. For example if you have two copies of a customer table, and the customer table is configured to be accessed on two servers one copy may always be fetched from one server, and one from the other, or it may happen that both are accessed on the same server. The server to be accessed is determined using an index into the list of possible servers based on a random number assigned when the database is opened, and the memory location and table number being read. Closing and reopening the database changes the random number and hence may change the server. Updating the network layout table will cause a different server to be accessed if the server in the chosen position is changed.
If the server first selected is offline, AUXDISTR will try the remaining server(s) sequentially from the chosen starting position.
The motivation for this change is to make secondary indexes work reliably. However, the problem described in AUXDISTR and Secondary Indexes may still arise if a server goes offline between successive calls to fetch(NEXT) or fetch(PREV)
Update operations involving a table (rec_post(),rec_kill() and rec_autoinc()) held on more than one server are broadcast to all the relevant machines. Usually this can only apply to Multiple Resilience Configurations. However, if the Local Database Resilience using the -nofail error handling option is in effect, updates destined for the remote server are initially posted locally as well. At commit time, such updates are discarded from the local database unless the remote server is offline.
This section applies to both Local Datase Resilience and Multiple Resilience Configurations.
In a Resilience Configuration network failures can give rise to commit failures. This is described in Effect of Networking on Commit Failures.
If the updates performed during a single transaction are distributed between more than one server, DP4 needs to invoke special handling for committing the transaction. This special handling is described in Implementation of Commits.