In the default implementation of threaded applications against a DB2 database, serialization of access to the database is enforced by the database APIs. If one thread performs a database call that is blocked for some reason (that is, the table is already in exclusive use), all other threads will be blocked as well. In addition, all threads within a process share a commit scope. True concurrent access to a database can only be achieved through separate processes, or by using the APIs that are described in this section.
This section describes APIs that can be used to allocate and manipulate separate environments (contexts) for the use of database APIs and embedded SQL. Each context is a separate entity, and any connection or attachment using one context is independent of all other contexts (and thus all other connections or attachments within a process). In order for work to be done on a context, it must first be associated with a thread. A thread must always have a context when making database API calls or when using embedded SQL. If these APIs to manipulate contexts are not used, all threads within a process share the same context. If these APIs are used, each thread can have its own context. It will have a separate connection to a database or attachment to an instance, and will have its own commit scope.
Contexts need not be associated with a given thread for the duration of a connection or attachment. One thread can attach to a context, connect to a database, detach from the context, and then a second thread can attach to the context and continue doing work using the already existing database connection. Contexts can be passed around among threads in a process, but not among processes.
If the new APIs are not used, the old behavior is in effect, and existing applications need not change.
Even if the new APIs are used, the following APIs continue to be serialized:
The new APIs can be used with embedded SQL and the transaction APIs.
These APIs have no effect (that is, they are no-ops) on platforms that do not support application threading.
Notes:
On AIX Version 4.2.1 or greater, the environment variable EXTSHM (=ON) can be used to enhance the number of shared memory regions to which a process can attach.
On AIX prior to Version 4.2.1, there are no operating system-based solutions. An alternative is to move the local database or DB2 Connect into another machine and to access it remotely, or to access the local database or the DB2 Connect database with TCP/IP loop-back by cataloging it as a remote node that has the TCP/IP address of the local machine.