Local and remote application processes can work with the same database. A remote application is one that initiates a database action from a machine that is remote from the database machine. Local applications are directly attached to the database at the server machine.
Each of the circles of the following figure represent engine dispatchable units (EDUs) which are known as "processes" on UNIX platforms, and "threads" on Windows NT and OS/2 platforms.
Figure 73. Process Model Overview
|
A means of communicating between an application and the database manager must be established before the work the application wants done at the database can be carried out.
In the figure above at A1, a local client establishes communications first by working with the db2ipccm engine dispatchable unit (EDU). This EDU at A2 works with a db2agent EDU that becomes the coordinator agent for the application requests from the local client. The coordinator agent contacts the client application at A3 and establishes shared memory and semaphores communication between the client application and the database at A4. The application at the local client is connected to the database.
In the figure above at B1, a remote client establishes communications first by working with the db2tcpcm EDU. If another communications protocol was chosen, the appropriate EDU would be used. The db2tcpcm EDU, at B2, works with a logical agent. This EDU at B3, works with a db2agent EDU that becomes the coordinator agent for the application requests from the remote client. The coordinator agent contacts the client application at B4 and establishes TCP/IP communication between the client application and the database at B5. The application at the remote client is connected to the database.
Other things to notice in this figure:
Figure 74. Process Model Part 2
 |
This figure shows additional engine dispatchable units (EDUs) that are part of the server machine environment. Each active database has its own shared pool of prefetchers (db2pfchr) and page cleaners (db2pclnr), and its own logger (db2loggr) and deadlock detector (db2dlock).
The circles labelled "db2udfp" and "db2dari" at the botton right of the figure represent processes run within DB2 Universal Database as fenced User-defined Functions (UDFs) and Stored Procedures respectively. These processes are managed in order to minimize costs associated with their creation and destruction. The default for the keepdari database manager configuration parameter is "YES" which keeps the stored procedure process available for re-use at the next stored procedure call.
| Note: | There are also unfenced UDFs and Stored Procedures which run directly in an agent's address space. By working this way, there is better performance. However, because they have unrestricted access to the agent's address space, they need to be rigorously tested before being used. |
Refer to the stored procedure chapter in the Application Development Guide for more information.
The multiple partition processing model is a logical extension of the single partition processing model. In fact, a single common code-base supports both modes of operation. The following figure is used to show the similarities and differences that exist between the single partition processing model as seen in the previous two figures, and the multiple partition processing model.
Figure 75. Process Model and Multiple Partitions
 |
The majority of engine dispatchable units (EDUs) are the same between the single partition processing model and the multiple partition processing model.
In a multiple partition (or node) environment, one of the partitions must be considered the catalog node. The catalog keeps all of the information relating to the objects in the database.
As shown in the figure above, because Application A creates the PROD database on Node0000, the catalog for the PROD database is created on this node. Similarly, because Application B creates the TEST database on Node0001, the catalog for the TEST database is created on this node. You may wish to create your databases on different nodes because you will always want to balance the extra activity associated with the catalogs for each database across the nodes in your system environment.
There are additional EDUs (db2pdbc and db2fcmd) associated with the instance and these are found on each node in a multiple partition database environment. These EDUs are needed to coordinate requests across database partitions and to enable the Fast Communication Manager (FCM).
There is also an additional EDU (db2glock) associated with the catalog node for the database. This EDU controls global deadlock situations across the nodes where the active database is located.
Each CONNECT from an application is represented by a logical agent at the database and results in a single coordinator agent. The coordinator agent exists on the partition to which the application connected. This partition then becomes the "Coordinator Node" for that application. The coordinator node can also be set using the SET CLIENT CONNECT_NODE command. Parts of the database requests from the application are divided by the coordinator node to subagents at the other partitions; and all results from the other partitions are consolidated at the coordinator node before being sent back to the application.
The database partition where the CREATE DATABASE command was issued is called the "Catalog Node" for the database. It is at this database partition that the catalog tables are stored. Typically, all user tables are partitioned across a set of nodes.