Distributed support

 

DB2^® UDB for iSeries™ supports these 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 protocol used between systems affects whether the network connection is protected or unprotected. Before V5R1, TCP/IP connections were always unprotected; thus they could 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 system over TCP/IP, updates can be performed over it, but any subsequent connections, even over Advanced Program-to-Program Communication (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, do a RELEASE ALL followed by a COMMIT to end all SQL connections before doing the CONNECT TO remote-tcp-system.

• Determining the connection type
  When a remote SQL connection is established, it uses either an unprotected or a protected network connection.

• Connect and commitment control restrictions
  There are restrictions on when you can establish the connection using commitment control. The restrictions also apply if you attempt to run statements using commitment control, but you specified COMMIT(*NONE) on the connection.

• Determining the connection status
  A CONNECT statement without parameters can be used to determine whether the current connection is updatable or read-only for the current unit of work.

• Distributed unit of work connection considerations
  When you connect in a distributed unit of work application, consider these points.

• Ending connections
  Because remote SQL connections use resources, end the connections that are no longer used, as soon as possible. You can end connections implicitly or explicitly.

 

Parent topic:

Distributed relational database function and SQL