Unprotected entry threads for critical transactions
Unprotected entry threads for critical transactions are
defined with the following DB2ENTRY parameters: PROTECTNUM(0)
and THREADLIMIT(n)
.
This is the recommended type of definition 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 critical transactions are created,
used, and terminated as follows:
- TCB attach
- No thread TCBs are attached when the CICS DB2 attachment facility
is started.
A TCB is attached only if needed by a thread.
- Thread creation
- A thread is created only when needed by a transaction.
When CICS is connected to DB2 (and so is using the open transaction environment), if no thread is available, but an open TCB can be used as a thread TCB for this DB2ENTRY, a new thread is created and related to the TCB, provided THREADLIMIT is not exceeded. If TCBLIMIT is reached, no more open TCBs can be used as thread TCBs for the DB2ENTRY.
- Thread termination
- The thread is terminated immediately after it is released, unless it has a transaction queued for it.
- Thread reuse
- Other transactions specified to use the same DB2ENTRY can reuse a thread, if it is available. This happens only if a transaction is waiting for the thread when the thread becomes available.
- Overflow to pool
- If THREADWAIT=POOL is specified, requests for threads are transferred to the pool when the value of THREADLIMIT
is exceeded. When a transaction overflows to the pool, the transaction
is now controlled by the PRIORITY, THREADLIMIT, and THREADWAIT attributes
that are specified for pool threads in the DB2CONN definition, and
those attributes in the DB2ENTRY definition are ignored. The remaining
attributes that are specified in the DB2ENTRY definition for the entry
thread still apply to the transaction, that is, ACCOUNTREC, AUTHID
or AUTHTYPE, DROLLBACK, and PLAN or PLANEXITNAME. The PROTECTNUM attribute
in the DB2ENTRY definition is no longer relevant for a transaction
that overflows to the pool, so this setting is ignored.
Note that you should not allow overflow to the pool for limited concurrency transactions.