The transaction scenario described in "Connecting to One or More Data Sources" portrays an application which interacts with only one database server in a transaction. Even though concurrent connections allow for concurrent transactions, the different transactions are not coordinated.
With Distributed Unit of Work (coordinated distributed transactions), the application is able to access multiple database servers from within the same coordinated transaction. Some distributed unit of work environments involve the use of a Transaction Manager to coordinate two-phase commit among multiple databases. For detailed description of distributed unit of work, refer to the Administration Guide. This section describes how DB2 CLI applications can be written to use coordinated distributed unit of work.
First, consider the environment attribute (SQL_ATTR_CONNECTTYPE) which controls whether the application is to operate in a coordinated or uncoordinated distributed environment. The two possible values for this attribute are:
All connections within an application must have the same SQL_ATTR_CONNECTTYPE setting. It is recommended that the application set this environment attribute, if necessary, as soon as the environment handle has been created with a call to SQLAllocHandle() (with a HandleType of SQL_HANDLE_ENV). Since ODBC applications cannot access SQLSetEnvAttr(), they must set this using SQLSetConnectAttr() before any connection has been established.