There are several different threading models in which SQL Contexts can be used. They are known as:

The Adabas SQL Gateway client support libraries support all three threading models.

See Implementing the Threading Models for information on how to implement these threading models.

This is the trivial case in which an application has only one thread and one SQL Context. This model is limited in its ability to serve multiple users in the sense that each request cannot assume any previous SQL Context. If such a context is required, then it must be recreated for each request, which is inefficient in terms of processing resources.

In this model, an application has multiple threads, and an equal number of SQL Contexts. Each thread has one SQL Context which is "bound" to it. Each thread can use only the SQL Context that is bound to it.

The Bound Threading model is simply the multi-threaded generalization of the Single Threading model and, therefore, suffers from the same drawback. If the Bound Threading model is used to service multiple users, each thread must either be locked for a specific user for the duration of the user's request in order to protect the SQL Context, or the thread must recreate the SQL Context at the start of each request.

However, if the application requirements are such that efficiency is not a priority, then the Bound Threading model can offer a useful compromise between the inefficiency of the Single Threading model and the extra programming effort required for the Free Threading model.

This is the most flexible threading model. In this model, the application has multiple threads and multiple SQL Contexts. However, the SQL Contexts are not bound to a specific thread - any thread can use any SQL Context. Consequently, the number of SQL Contexts can be greater than the number of threads. It is then possible to allocate one SQL Context for each logical user of the application. For example, for an internet-accessible application, you'd allocate one SQL Context for each web browser that is accessing the application.

This allows for efficient applications where the stream of requests from the user population is processed by multiple worker threads in a Multiple Server/Single Queue (MSSQ) configuration. MSSQ has the advantage of automatic load balancing between the worker threads, making it more likely that requests will be processed in the shortest possible time.

In this model, the SQL application is responsible for controlling which thread can access which SQL Context. As a consequence of this, it is possible (although not desirable) for more than one thread to simultaneously attempt to use the same SQL Context. In order to protect the integrity of SQL Contexts, the client support libraries of the Adabas SQL Gateway implement a locking mechanism to ensure that only one thread can use an SQL Context at any time.

This locking mechanism is largely transparent to the application writer. However, applications should ideally implement their own locking strategy to control access to the SQL Contexts or at least be able to cope with the situation that a thread finds an SQL Context to be locked already by another thread.