Selecting thread types for optimum performance
To optimize performance, select the thread type to use for a set of transactions together with the BIND parameters for the corresponding plan.
Selecting the thread type and BIND parameters together is important because the BIND parameters determine whether a number of activities are related to the thread or to the transactions. For more information, see Selecting BIND options for optimum performance.
- Protected entry threads
- Protected entry threads are recommended for:
- High-volume transactions of any type
- Terminal-oriented transactions with many commits
- Non-terminal-oriented transactions with many commits (if NONTERMREL=YES is specified in the DB2CONN)
- Unprotected entry threads for critical transactions
- Unprotected entry threads for critical transactions are recommended
for:
- Critical transactions requiring a fast response time, but with a volume so low that a protected thread cannot be used
- Limited concurrency transactions
- Unprotected entry threads for background transactions
- Unprotected entry threads for background transactions are recommended for transactions with low volume that do not require a fast response time. All transactions are forced to use pool threads.
Using protected threads (by specifying PROTECTNUM=n on the DB2ENTRY definition for an entry thread) is a performance option that reduces the resources involved in creating and terminating a thread. A protected thread is not terminated when a transaction ends, and the next transaction associated with the same DB2ENTRY reuses the thread. By using protected threads, you eliminate much of the work required for thread creation and termination for individual transactions. For performance reasons, it is recommended that you use protected entry threads whenever possible, and especially where a transaction is frequently used, or issues many SYNCPOINTS. The main exception is when a transaction is infrequently used, because even a protected thread is likely to terminate between such transactions.
From an accounting viewpoint, the situation is different. An accounting record is produced for each thread termination and for each new user signon. This means that only one accounting record is produced if the thread stays alive and the user ID does not change. This record contains summarized values for all transactions using the same thread, but it is not possible to assign any value to a specific transaction. This can be overcome by specifying ACCOUNTREC(UOW) to make sure an accounting record is cut per unit of work, or by specifying ACCOUNTREC(TASK) to make sure there is an accounting record cut per CICS task. See Monitoring DB2 for more information about accounting in a CICS DB2 environment.
Several transactions can be specified to use the same DB2ENTRY. Ideally, they should all use the same plan. Each low-volume transaction can have its own DB2ENTRY. In this case thread reuse is not likely and you should specify PROTECTNUM=0. An alternative is to group a number of low-volume transactions in the same DB2ENTRY and specify PROTECTNUM=n. This gives better thread utilization and less overhead.
Authorization checks take place when a thread is created and when a thread is reused with a new user. Avoiding the overhead in the security check is part of the performance advantage of using protected threads. This means that from a performance viewpoint all transactions defined to use the same DB2ENTRY with PROTECTNUM>0 should use the same authorization ID. At least they should avoid specifying TERM, OPID, and USERID for the AUTHTYPE parameter, because these values often vary among instances of a transaction.
It is important that you coordinate your DB2CONN, DB2ENTRY, and BIND options. For more information, see Coordinating your DB2CONN, DB2ENTRY, and BIND options.