Thread Reuse
The term thread reuse only applies to IMS and CICS® attachments. In the case of the TSO attachment facility and the call attachment facility (CAF), threads cannot be reused, because the threads are allocated to the user address space.
- If transaction volume is high:
High volume transactions should achieve a high percentage of thread reuse. If threads are reused on low volume transactions, the number of threads needed increases because these threads are not automatically terminated by IMS when not being used. This can result in too many idle threads for the level of the DB2® workload. Under CICS, protected threads are terminated after the purge cycle if no transaction eligible to reuse the thread has been received.
- If thread creation cost is significant:
As a rule of thumb, more than 5% of the total CPU cost of transaction processing is considered significant.
- If most of the application plan's SQL statements are executed, then ACQUIRE(ALLOCATE) is cheaper than ACQUIRE(USE).
- If only a small number of the SQL statements are executed, ACQUIRE(USE)
becomes cheaper and improves concurrency, because the required resources
are only acquired (locked) when the plan actually references (uses)
them. An example would be a generalized plan used by many different
transactions. It would contain multiple logic paths referencing different
tables.
If packages are involved, ACQUIRE(USE) is always implicitly used.
- Concurrency in thread reuse is based on page locking provided
by the IS and IX intent locks, whose duration is governed by ACQUIRE
and RELEASE of BIND.
RELEASE(DEALLOCATE) is recommended for thread-reuse transactions to reduce transaction CPU time.
When thread reuse is implemented, monitor the EDM pool. It should be sufficient in size to accommodate expanding plans where the next transaction requires additional plan sections over those already part of the EDM pool.