Transaction Server Overview

The Transaction Server is a multi-threaded application. Within the Transaction Server are a number of threads that are pre-allocated during system startup to manage API requests. The number of threads allocated fluctuates during the life of the Transaction Server. If a thread remains idle for a significant period of time it is released to free up system resources. If the load on the Transaction Server increases and if additional threads become necessary, they are allocated on an as-needed basis. The number of threads is controlled by the Transaction Server maxApiAgents profile parameter.

Whenever the client API connects to the Transaction Server, the request is passed to the API request queue where it waits for an available API thread. When an API thread becomes available, the thread is allocated to the client API. All client API requests are managed by a single thread until the client API issues a terminate request. The API thread is then released back into the API thread pool.

This technique guarantees that all the adjustments applied during the life of a client application connection are assigned a single adjustment identifier. The Transaction Server treats all requests issued between the initialize request and the terminate request as a single transaction. This means that updates, inserts, and delete requests can easily be undone by backing out of the transaction.

Tasks and event handlers are expected to be single-threaded. When executing a task or event handler, the Transaction Server makes a database connection available for use by the user exit. Tasks and event handlers are expected to be very responsive. If a task or an event handler takes a considerable amount of time to execute (anything longer than a second), it spawns a new thread and returns to the Transaction Server in a timely fashion.

Note: Do not use a database connection made available from the Transaction Server if creating a thread.