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.