Adabas Fastpath can be used to optimize Adabas databases that are remote to the client process while automatically maintaining the integrity of data in the Adabas Fastpath buffer.
The following graphic shows the communication components and path involved in a client query, without Adabas Fastpath, when the data resides in a remote Adabas server:
An Entire Net-Work communicator with an appropriate access method line driver is installed on both systems. The two line drivers establish the connection with each other through the appropriate access method services.
Adabas Fastpath can be used to optimize a client query for data from a remote database where the Adabas Fastpath buffer is in the same operating system image as the client. Entire Net-Work makes the location of the database transparent to the optimization process and there are no special installation requirements.
When a command is optimized by Adabas Fastpath (that is, satisfied from the Adabas Fastpath shared memory buffer), the Entire Net-Work communication path is bypassed as well as the Adabas command processing.
This section describes the update notification processing used to maintain data integrity in the Fastpath Buffer(s).
In a single system implementation or a multisystem implementation where the Fastpath Buffer is in the same operating system image as (that is, local to) the updated Adabas server, the Fastpath Buffer Manager enlists with the Adabas server according to their defined file parameters.
When the Fastpath component in the Adabas server is subsequently notified of an update, the details are immediately reflected in the Fastpath Buffer as depicted below:
In a multisystem implementation where the Fastpath Buffer is not local to the updated Adabas server, the remote Fastpath Buffer Manager enlists with the Adabas server according to the Update Sensitivity of their defined file parameters.
When the Fastpath component in the Adabas server is subsequently notified of an update, it forwards the update notification to its local COR daemon which forwards it to the COR daemon local to the remote Fastpath Buffer. On receipt, this COR daemon forwards the update notification to the Fastpath Buffer Manager and the details are immediately reflected in the Fastpath Buffer as depicted below:
In a multisystem implementation where multiple Fastpath buffers are both local and remote to the updated Adabas server, each Fastpath Buffer Manager enlists with the Adabas server according to the Update Sensitivity of their defined file parameters.
When the Fastpath component in the Adabas server is subsequently notified of an update, it uses a combination of the update signalling described in the previous sections. Updates are reflected in the Fastpath Buffers either directly by the Adabas Fastpath component in the Adabas server or indirectly by COR daemon forwarding as depicted below:
With Adabas Cluster Services, instances of an Adabas server may exist both locally and remotely. To ensure data integrity in the Fastpath Buffer there must be a COR daemon in every operating system image where an Adabas server instance is active.
The Fastpath Buffer Manager enlists with all instances of the Adabas server according to the Update Sensitivity of their defined file parameters.
Note:
For files residing on ALS databases, the
Update Sensitivity is
automatically set to "D" (Distributed record level) at
runtime.
Using a combination of the update signalling described in the previous sections, update notifications from all instances of the Adabas server are reflected in the Fastpath Buffer either directly by the Adabas Fastpath component in the Adabas server instance or indirectly by COR daemon forwarding as depicted below:
With Adabas Cluster Services, instances of an Adabas server may exist both locally and remotely. To ensure data integrity in each Fastpath Buffer there must be a COR daemon in every operating system image where an Adabas server instance is active.
Each Fastpath Buffer Manager enlists with all instances of the Adabas server according to the Update Sensitivity of their defined file parameters.
Note:
For files residing on ALS databases, the
Update Sensitivity is
automatically set to "D" (Distributed record level) at
runtime.
Using a combination of the update signalling described in the previous sections, update notifications from all instances of the Adabas server are reflected in each Fastpath Buffer either directly by the Adabas Fastpath component in the Adabas server instance or indirectly by COR daemon forwarding.
The following diagram shows how an update in Adabas Server Instance 1 is reflected in each Fastpath Buffer:
The following diagram shows how an update in Adabas Server Instance 2 is reflected in each Fastpath Buffer:
In large multisystem implementations it is likely that multiple Fastpath Buffer Managers will enlist with the same Adabas server. In such cases, the update signalling cycle will take longer. You will need to consider the number of updates processed to determine the optimization benefits.
In a multisystem implementation where COR daemon forwarding is used to signal update notifications to remote Fastpath Buffers, if an individual COR daemon is unilaterally brought down then update notifications from Adabas servers in that operating system image can no longer be forwarded to any remote Fastpath Buffers. Under these circumstances, and in order to protect data integrity within the Fastpath Buffers, direct-access optimization will automatically be switched off for those files that rely upon COR daemon forwarding for update notifications. Such files are identified by having a defined File Parameter Update Sensitivity of value "D" (Distributed record level).
Note that an AFP RESTART or NEWCOPY issued to any COR daemon will cause all active Fastpath Buffers in the multisystem group to be re-initialized. Direct-access optimization will resume. Refer to Operator Commands for additional considerations regarding the use of AFP RESTART and NEWCOPY in multisystem implementations.