Enabling pooling of DBATs

Enabling threads to be pooled provides the following advantages:

• You can leave workstation applications connected to Db2 from the first activation until the workstation is shut down, and thus avoid the delay of repeated connections.
• Db2 can support a larger number of distributed connections that are limited by the value of CONDBAT subsystem parameter because the number of connections is not limited by the maximum number of threads.
• Less storage is used for each DDF connection because a connection uses significantly less storage than a database access thread.
• You get an accounting trace record each time that a thread is pooled, rather than a single record for the duration of the connection. When a pooled thread becomes active, the accounting fields for that thread are reinitialized. As a result, the accounting record contains information about active threads only, which makes it easier to study the performance of distributed applications. If a pooled mode thread remains active because of sections that are specified with the KEEPDYNAMIC(YES) bind option, an accounting record is still written.
  Exception: If you employ account record accumulation, an accounting trace is not produced each time that a thread becomes pooled. Accounting records can be rolled up by concatenated combinations of the following values:

  • User ID
  • End transaction name
  • User workstation name
• Each time that a thread is pooled, Workload Manager resets the information that it maintains on that thread. The next time that thread is activated, workload manager begins managing to the goals that you set for the transactions that run in that service class. If you use multiple performance periods, it is possible to favor short-running units of work that use fewer resources while giving fewer resources over time to long running units of work.
• You can use response time goals, which is not recommended when ACTIVE mode threads are used.
• INACTIVE mode threads can better take advantage of the ability to time out idle active threads.
• Thread reuse enables DDF to use a small pool of database access threads to support a large group of network clients.
• The response times that RMF reports include periods between requests and within the same unit of work. These times are shown as idle delays.