The cost of creating a thread can be significant and reusing
threads is a way to avoid that cost.
About this task
In general, you want transactions to reuse threads when
transaction volume is high and the cost of creating threads is significant,
but thread reuse is also useful for a lower volume of priority transactions.
For a transaction of five to ten SQL statements (10 I/O operations),
the cost of thread creation can be 10% of the processor cost. But
the steps needed to reuse threads can incur costs of their own.
Procedure
To reduce the costs of creating many threads, use the
following approaches:
- For
allied threads, bind plans with the RELEASE(DEALLOCATE) option.
RELEASE(DEALLOCATE)
does not free cursor tables (SKCTs) at a commit point. Therefore,
the cursor table could grow as large as the plan. If you are using
created temporary tables, the logical work file space is not released
until the thread is deallocated. Thus, many uses of the same created
temporary table do not cause reallocation of the logical work files,
but be careful about holding onto this resource for long periods of
time if you do not plan to use it.
- For database access threads, enabled threads to be pooled
at the Db2 server
As a server,
Db2 can assign
that connection to a pooled database access thread. Those threads
can be shared and reused by thousands of client connections, which
lets
Db2 support
very large client networks at minimal cost. (Inactive threads are
only eligible to be reused by the same connection.)
If your server
is not Db2 for z/OS®,
or some other server that can reuse threads, then reusing threads
for your requesting CICS®, IMS, or RRS applications is not a
benefit for distributed access. Thread reuse occurs when sign-on occurs
with a new authorization ID. If that request is bound for a server
that does not support thread reuse, that change in the sign-on ID
causes the connection between the requester and server to be released
so that it can be rebuilt again for the new ID.