Distributed support

DB2^® UDB for iSeries™ supports two levels of distributed relational database.

Remote unit of work (RUW)
Remote unit of work is where the preparation and running of SQL statements occurs at only one application server during a unit of work. An activation group with an application process at an application requester can connect to an application server and, within one or more units of work, run any number of static or dynamic SQL statements that refer to objects on the application server. Remote unit of work is also referred to as DRDA^® level 1.
Distributed unit of work (DUW)
Distributed unit of work is where the preparation and running of SQL statements can occur at multiple applications servers during a unit of work. However, a single SQL statement can only refer to objects located at a single application server. Distributed unit of work is also referred to as DRDA level 2.

Distributed unit of work allows:
- Update access to multiple application servers in one logical unit of work
  or
- Update access to a single application server with read access to multiple application servers, in one logical unit of work.
Whether multiple application servers can be updated in a unit of work is dependent on the existence of a sync point manager at the application requester, sync point managers at the application servers, and two-phase commit protocol support between the application requester and the application servers.

The sync point manager is a system component that coordinates commit and rollback operations among the participants in the two-phase commit protocol. When running distributed updates, the sync point managers on the different systems cooperate to ensure that resources reach a consistent state. The protocols and flows used by sync point managers are also referred to as two-phase commit protocols. If two-phase commit protocols will be used, the connection is a protected resource; otherwise the connection is an unprotected resource.

The type of data transport protocols used between systems affects whether the network connection is protected or unprotected. Before V5R1, TCP/IP connections were always unprotected; thus they can participate in a distributed unit of work in only a limited way. In V5R1, full support for DUW with TCP/IP was added. For example, if the first connection made from the program is to a pre-V5R1 server over TCP/IP, updates can be performed over it, but any subsequent connections, even over APPC, will be read-only.

Note that when using Interactive SQL, the first SQL connection is to the local system. Therefore, in the pre-V5R1 environment, in order to make updates to a remote system using TCP/IP, you must do a RELEASE ALL followed by a COMMIT to end all SQL connections before doing the CONNECT TO remote-tcp-system.

Determine connection type
When a remote connection is established it will use either an unprotected or protected network connection.
Connect and commitment control restrictions
There are some restrictions on when you can connect using commitment control. These restrictions also apply to attempting to run statements using commitment control but the connection was established using COMMIT(*NONE).
Determine connection status
The CONNECT statement without parameters can be used to determine if the current connection is updatable or read-only for the current unit of work. A value of 1 or 2 will be returned in SQLERRD(3) in the SQLCA or DB2_CONNECTION_STATUS in the SQL diagnostic area.
Distributed unit of work connection considerations
When connecting in a distributed unit of work application, there are many considerations.
End connections
Because remote connections use resources, connections that are no longer going to be used should be ended as soon as possible. Connections can be ended implicitly or explicitly.

Parent topic: Distributed relational database function and SQL