You should select the thread type to use for a given set of transactions together with the BIND parameters for the corresponding plan. This is because the BIND parameters determine whether a number of activities are related to the thread or to the transactions. For advice on selecting BIND parameters, see Selecting BIND options for optimum performance.
As we have read in How threads are created, used, and terminated, protected entry threads are recommended for:
Unprotected entry threads for critical transactions are recommended for:
You could use a protected thread for limited concurrency transactions, if the transaction rate makes it possible to reuse the thread.
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 Accounting and monitoring in a CICS DB2 environment 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.