Timeouts enable the database to handle exceptional situations after a certain period of time. The intervals at which timeouts occur can be configured via the ADABAS CONTROL component and depend on the type of application. They are stipulated in such a way that timeouts will not normally occur. Nevertheless, every program must check the timeout sqlcodes and then handle them either via the whenever sqlexception condition or via an explicit test following every SQL statement.
The following timeouts exist:
request timeout (sqlcode +500)
Cause:
The program has waited for a lock for a longer period of time than is specified in the installation parameter 'request timeout'. The lock is not available. Control is returned to the program.
Action:
In principle, the lock can be requested again or the statement which implicitly requested the lock can be repeated. If the program holds its own locks, these should be returned via 'rollback work' after a 'request timeout'. Then the lock which could not be obtained may be requested again as the first lock. The risk of deadlocks is reduced by this means. If in multiuser mode the 'request timeout' occurs frequently in spite of checking the installation parameter, the transaction should be revised to provide more efficient locking (more single row locks, shorter transactions, another ADABAS lock mode). For long transactions which successively process several tables, all the required tables or table rows should be locked explicitly at the beginning of the transaction. This method reduces the risk of deadlocks in the case of implicit locks (incremental lock request), but other users may be blocked for a longer time.
lock timeout (sqlcode +600)
Cause:
The program holds a lock for a longer period of time than is specified in the installation parameter 'lock timeout'. ADABAS performs a rollback work on the current transaction. (This timeout is only activated when other users request the locked objects.) The message does not appear until the first statement is issued after the period of inactivity.
Action:
The last transaction must be repeated. The cause for the timeout should be checked (e.g., no user interaction when holding locks; the same applies to long computations).
session timeout (sqlcode +700)
Cause:
The program has not issued an SQL statement for a period longer than is specified in the installation parameter 'session timeout'. ADABAS performs a 'rollback work release' on the current transaction, thus disconnecting the program from the database.
Action:
The program must re-issue the connect statement and repeat the last transaction. If result tables are used, these must be built up again via the select statement.
Waiting for user input can involve a lengthy period of time. User input should therefore be entered immediately after a 'commit work'. Thus the program holds no locks; therefore it does not hinder other users and there is no risk of a 'lock timeout'.
If a 'session timeout' occurs subsequent to a 'commit work', it has no effect on the current transaction.