Transparency of Redundant Systems
The network operator is responsible for provisioning to only one PDBA. Once the active PDB is
provisioned, the system automatically passes down the data to the active and standby RTDBs on that
EAGLE 5 ISS. At the same time, the data is also passed, asynchronously, to the standby PDB and
subsequently to the mated RTDBs on the mated EAGLE 5 ISS. Provisioning of redundant systems,
therefore, is transparent to the user.
When the active PDBA becomes unavailable, the standby PDBA does not automatically switch to
active. The PDBA client must send a switchover command to tell the standby PDBA to become active.
Logs
Several logs are available to the user, including a Command Log, which contains a trace of the
commands sent to the PDBA, and an Error Log, which contains a trace of all errors encountered during
provisioning, in addition to several other options.
Crash Recovery
If a crash occurs while a transaction is in process and does not cause database corruption, the database
remains in the state before the crash after the reboot.
In the event of a catastrophic failure or corruption of a database, several options exist for reloading
the data. For more information, refer to the EPAP Administration Manual.
Request IDs
Each request has an ID, called the ‘iid’, as its first element. Its purpose is to allow responses to be
matched up with requests as they arrive back at the client. Its value is an integer between 1 and
4294967295, expressed as a decimal number in ASCII.
The iid is optional. If an iid is not provided on a request, the corresponding response also does not
have one. The iid is selected by the client when a command is sent and the selected value is returned
by the PDBA in the subsequent response. A different iid could be selected for each request.
Multiple Session Connectivity
Multiple information systems can be connected via the PDBI simultaneously. All systems can open
read transactions, but only one system at a time can open a write transaction. If more than one system
requests a write transaction, contention for write access is handled as follows:
• The first user to submit a write request is granted access, if it is authorized for write access.
• If a second user submits a write request while the first transaction is still open, the second user is
either immediately rejected or is queued for a specified timeout period.
• The time out period can be specified by the user in the write request as a value from 0 to 3600
seconds. If the value is not included or is set to 0, the second write request is immediately rejected.
• If the time out value is set to any non-zero value, the second request is held for that time period
before being rejected. If the first user releases the write transaction before the second user time out
period has expired, the second user is then granted write access.
• If a third user submits a write request after the second user with a specified time out period, the
third user's request is queued behind the second user's request. When the first user releases the
transaction, the second user is granted access. After the second user releases the transaction, the
29
910-6022-001 Revision A, March 2011
Functional DescriptionProvisioning Database Interface Manual
To Next Page
Loading...
