Adaptive Server uses the transaction descriptor resource to manage transactions within a server. A transaction descriptor is an internal memory structure that Adaptive Server uses to represent a transaction.
Upon starting, Adaptive Server allocates a fixed number of transaction descriptors based on the value of the configuration parameter txn to pss ratio and places them in a pool. Adaptive Server obtains transaction descriptors from the pool as they are needed for new transactions. As transactions complete, descriptors are returned to the pool. If there are no transaction descriptors available, transactions may be delayed as Adaptive Server waits for descriptors to become freed.
To properly configure the number of transaction descriptors, it is important that you understand exactly when Adaptive Server tries to obtain new descriptors from the global pool. A new transaction descriptor is required when:
A client connection initiates a new, outer-level transaction. This can occur explicitly, when the client executes an outer-level begin transaction command. It can also occur implicitly, when a client modifies data without entering a begin transaction command.
Once an outer-level transaction has begun, future nested begin transaction commands do not require additional transaction descriptors. Allocation and deallocation of the transaction descriptor is dictated by the outer-most block of the transaction.
An existing transaction modifies a second database (a multi-database transaction). A multi-database transaction requires a dedicated transaction descriptor for each database it accesses.
Figure 2-1 illustrates how Adaptive Server obtains and releases transaction descriptors for different transaction types.
Figure 2-1: Allocating and deallocating transaction descriptors
In Figure 2-1, Adaptive Server uses a total of three transaction descriptors for User 1, who accesses the server through a pair of client connections. The server allocates a single descriptor for transaction allwork, which is freed when that transaction commits. The nested transaction, nested1, does not require a dedicated transaction descriptor.
Transaction addlead, a multi-database transaction, requires two transaction descriptors—one for the outer transaction block, and one for modifying a second database, datastore2. Both transaction descriptors are released when the outer transaction block commits.
User 2, accessing Adaptive Server from isql, also requires a dedicated transaction descriptor. Even though User 2 did not explicitly create an outer transaction block with begin transaction, Adaptive Server implicitly creates a transaction block to execute the update command. The transaction descriptor associated with this block is acquired after the go command, and released after the insert has completed.
Because transaction descriptors consume memory that can be used by other Adaptive Server services, it is important that you use only enough descriptors to satisfy the maximum number of transactions that may be required at any given time.
