ITEM: AV6900L

fup 03/08.question concerning db2 6000 thread support/does db2 support

Env:

db2v2.1 aix 4.1, mtype 58H

Desc:

Does db2 support multiple thread acces out of single process
Does db2 support dce thread??

Action:

Continued research again today but still could not find any documentation
on it. Only could find the fact that db2 is support in a dce 
environment. At this time I will request support from toronto.

Action:  

Sandy call and I told him that in my research I found out
that db2 v2 does not use threads even when installed on aix4.1. Faxed
him information gathered via db2help
-- click search
 -search for: threads
 -select 'All Libraries' option
-- \
-- Double click 'Database Agent' from the list

Response:

     
     Note Regarding Multi-Threaded Environments 

     The database manager can take advantage of the multi-threaded capabilities 
     of the operating system, if the minimum required level of the operating 
     system (see your Planning Guide) supports threads. 

     For example, the minimum version of AIX required is Version 3.2.4 which 
     does not support threads, and therefore DB2 for AIX does not use threads, 
     even when installed on AIX Version 4.1. The minimum required version of 
     OS/2, for example, is Version 2.11 which supports threads, and therefore 
     DB2 for OS/2 will use threads. 

     If your version of the database manager takes advantage of multi-threaded 
     operating system capabilities, you can substitute "threads" in place of 
     "processes" in the remainder of this section. 

 A unique and independent agent process is assigned to handle the different 
 requests to use the facilities of the database manager  (that is, to access a 
 database, take a snapshot of an application, or attach to a database manager 
 instance), whether from a remote or local client. Each agent process operates with 
 its own private memory and shares the database manager and database global 
 resources such as the buffer pool with other agents. 

 An agent process can either be active or idle.  Active agents are assigned to a 
 client and perform work for that client. Idle agents are not performing work on 
 behalf of any clients and are waiting to be assigned to a client. If no idle agents 
 exist when a client requires one, a new agent is dynamically created. Creating a 
 new agent involves a certain amount of overhead and as a result, improved 
 CONNECT and ATTACH performance can be noticed if there is an idle agent that 
 can be activated for a client. The number of idle agents will not exceed the value 
 given by the max_idleagents configuration parameter (see Maximum Number of 
 Idle Agents (max_idleagents)). When a client disconnects from a database or 
 detaches from an instance the agent will be: 

   o  Freed and marked as idle, if the maximum number of idle agents has not 
      been reached 
   o  Terminated and its storage freed, if the maximum number of idle agents has 
      been reached. 
  Once the number of agents reaches the value given by the maxagents 
 configuration parameter (see Maximum Number of Agents (maxagents)), all 
 subsequent requests that require a new agent are denied until the number of 
 agents falls below maxagents. 

 For each database transaction (unit of work) that occurs when the client is 
 connected to a database, an agent will attempt to obtain permission to process the 
 transaction, known as a processing token, from the database manager.  Only 
 agents with a token are permitted by the database manager to execute a unit of 
 work against a database; the number of tokens available is controlled by the 
 maxcagents configuration parameter (see Maximum Number of Concurrent 
 Agents (maxcagents)). If a token is not available, the agent will wait until one is 
 available, at which time the requested unit of work will be processed. 

 In addition to the database agents, there are other asynchronous activities 
 performed by the database manager which run as their own process (or thread), 
 including: 

   o  Database I/O servers (or I/O prefetchers) (see Prefetching Data into the 
      Buffer Pool) 
   o  Database asynchronous page cleaners  (see Managing the Database Buffer 
      Pool) 
   o  Database deadlock detectors 
   o  Event monitors 
   o  Communication and IPC listeners 
   o  Table space container rebalancers. 
  Each of the above processes is initiated by a generic daemon spawner process.



Support Line: fup 03/08.question concerning db2 6000 thread support/does db2 support ITEM: AV6900L

Dated: March 1996 Category: N/A

This HTML file was generated 99/06/24~13:30:24

Comments or suggestions?
Contact us