Connection management and activation groups

 

SQL connections are managed at the activation group level. Each activation group within a job manages its own connections and these connections are not shared across activation groups.

Before the use of TCP/IP by Distributed Relational Database Architecture™ (DRDA^®), the term connection was not ambiguous. It referred to a connection from the SQL point of view. That is, a connection starts when you run the CONNECT TO statement to connect to some relational database (RDB), and ends when you run the DISCONNECT or RELEASE ALL statement followed by a successful COMMIT operation. The Advanced Program-to-Program Communication (APPC) conversation might or might not have been kept up, depending on the DDMCNV attribute value of the job and whether the conversation was with a System i™ product or with other types of systems.

TCP/IP terminology does not include the term conversation. A similar concept exists, however. With the advent of TCP/IP support by DRDA, use of the term conversation is replaced, in this topic, by the more general term connection, unless the discussion is specifically about an APPC conversation. Therefore, there are now two different types of connections about which the reader must be aware: SQL connections of the type described above, and network connections which replace the term conversation.

Where there might be the possibility of confusion between the two types of connections, the word will be qualified by SQL or network to help the reader to understand the intended meaning.

The following is an example of an application that runs in multiple activation groups. This example is used to illustrate the interaction between activation groups, connection management, and commitment control. It is not a recommended coding style.

• Source code for PGM1
  Here is the source code for PGM1.

• Source code for PGM2
  Here is the source code for PGM2.

• Source code for PGM3
  Here is the source code for PGM3.

• Multiple connections to the same relational database
  If different activation groups are connected to the same relational database, each SQL connection has its own network connection and its own application server job.

• Implicit connection management for the default activation group
  An application requester can be implicitly connected to an application server.

• Implicit connection management for nondefault activation groups
  An application requester can be implicitly connected to an application server. Implicit SQL connection occurs when the application requester detects that the first SQL statement issued for the activation group is not a CONNECT statement with parameters.

 

Parent topic:

Distributed relational database function and SQL