An application-directed distributed unit of work uses a Type 2 connection. A Type 2 connection connects an application process to the identified application server and establishes the rules for application-directed distributed unit of work.
Each connection of an application process is uniquely identified by the database alias of the application server of the connection.
At any time an individual connection has one of the following sets of connection states:
A type 2 application process is initially in the unconnected state and does not have any connections.
A connection initially is in the current and held state.
The following diagram shows the state transitions:
A different application server can be established by the explicit or implicit execution of a CONNECT statement. 10 The following rules apply:
If an application process has a current connection, the application process is in the connected state. The CURRENT SERVER special register contains the name of the application server of the current connection. The application process can execute SQL statements that refer to objects managed by that application server.
An application process in the unconnected state enters the connected state when it successfully executes a CONNECT or SET CONNECTION statement. If there is no connection in the application but SQL statements are issued, an implicit connect will be made provided the DB2DBDFT environment variable has been defined with a default database.
If an application process does not have a current connection, the application process is in the unconnected state. The only SQL statements that can be executed are CONNECT, DISCONNECT ALL, DISCONNECT specifying a database, SET CONNECTION, RELEASE, COMMIT and ROLLBACK.
An application process in the connected state enters the unconnected state when its current connection is intentionally ended or the execution of an SQL statement is unsuccessful because of a failure that causes a rollback operation at the application server and loss of the connection. Connections are intentionally ended either by the successful execution of a DISCONNECT statement or by the successful execution of a commit operation when the connection is in the release-pending state. Different options specified in the DISCONNECT precompiler option affect intentionally ending a connection. If set to AUTOMATIC, then all connections are ended. If set to CONDITIONAL, then all connections that do not have open WITH HOLD cursors are ended.
If an application process executes a CONNECT statement and the server name is known to the application requester and is not in the set of existing connections of the application process, then:
If the server name is already in the set of existing connections of the application process and the application is precompiled with the option SQLRULES(STD), an error (SQLSTATE 08002) is raised.
Even if a connection is not explicitly marked for release, it may still be disconnected by a commit operation if the commit operation satisfies the conditions of the DISCONNECT precompiler option.
When a connection is ended, all resources that were acquired by the application process through the connection and all resources that were used to create and maintain the connection are de-allocated. For example, if the application process executes a RELEASE statement, any open cursors will be closed when the connection is ended during the next commit operation.
A connection can also be ended because of a communications failure. The application process is placed in the unconnected state if the connection ended was the current one.
All connections of an application process are ended when the process ends.