When multi-transaction mode is in effect across multiple DBEnvironments with multiple applications accessing the same DBEnvironments at the same time, it is possible that a deadlock that cannot be detected by ALLBASE/SQL could occur. This is known as an undetectable deadlock. In addition, when multi-transaction mode is used with multiple connections to the same DBEnvironment, an infinite wait can occur.
To avoid these situations, be sure your timeout values are set to a
value other than NONE. (Note that NONE is the default when no timeout value is specified at DBEnvironment creation time.)
Undetectable Deadlock Prevention |
 |
Suppose your application is simultaneously connected to two DBEnvironments in multi-transaction mode. At the same time, another user's application is connected to the same DBEnvironments. At some point as these applications execute, each one has an active transaction
waiting for access to data locked by another transaction in the other
application. It is a classic deadlock, and since the data being waited for spans more than one DBEnvironment, ALLBASE/SQL cannot detect this deadlock. The two databases will wait "forever" unless you have set a TIMEOUT value other than NONE for one or both of the application connections.
Infinite Wait Prevention |
|
An application running in multi-transaction mode with multiple active transactions accessing data in the same DBEnvironment can encounter undetectable wait conditions. For instance, the first of two such transactions could be holding locks that cannot be released until the transaction is commited. And the second transaction could require the same locks in order to complete. The second transaction is waiting for the first to commit work, and the first transaction is waiting for the second to return control so that it can commit. Since both transactions are part of the same process, ALLBASE/SQL cannot detect this situation.
Unless timeouts are set for at least one of these transactions, they could wait infinitely.
It may not be possible to predict an undetectable wait. Even when
the transactions involved are accessing different tables, the physical
proximity of system catalog data could mean that locks held by transaction one are required by transaction two. This is particularly true in relation to DDL statements (including the UPDATE STATISTICS
statement, even though it is allowed in DML only mode) and dynamic space expansion.
To prevent an infinite wait, be sure to set appropriate timeout values and test for the occurrence of a timeout.
