Implicit transactions are automatically handled by the Integration Server transaction manager. When you define an explicit transaction, you define the start-on-completion boundaries of the transaction. As such, implicit and explicit transactions need to be created and managed differently.

The following sections describe implicit and explicit transactions and how to manage them.

With implicit transactions, Integration Server automatically manages both local and XAResource transactions without requiring you to explicitly do anything. That is, Integration Server starts and completes an implicit transaction with no additional service calls required by the adapter user.

A transaction context, which the transaction manager uses to define a unit of work, starts when an adapter service is encountered in a flow execution. The connection required by the adapter service is registered with the newly created context and used by the adapter service. If another adapter service is encountered, the transaction context is searched to see if the connection is already registered. If the connection is already registered, the adapter service uses this connection. If the connection is not registered, a new connection instance is retrieved and registered with the transaction.

Note that if the top level flow invokes another flow, adapter services in the child flow use the same transaction context.

When the top level flow completes, the transaction is completed and is either committed or rolled back, depending on the status (success or failure) of the top level flow.

A single transaction context can contain any number of XA_TRANSACTION connections but no more than one LOCAL_TRANSACTIxON connection. If you choose to provide dynamic user credentials at run time, then all the adapter services using the LOCAL_TRANSACTION connection within a single transaction must use the same user credentials. For example, if you have two adapter services s1 and s2 configured using the LOCAL_TRANSACTION connection c1 in a single transaction context, then both s1 and s2 must either use the same dynamic credentials at run time or the default configured credentials provided at design time. For more information on dynamic user credentials for a service's associated connection, see Changing the User Credentials of a Service's Associated Connection at Run Time.

For implicit transaction examples, see Implicit and Explicit Transaction Examples.

For more information about designing and using flows, see the webMethods Service Development Help for your release.

For more information about transaction types, see Transaction Management of Adapter Connections.

You use explicit transactions when you need to explicitly control the transactional units of work. To do this, you use additional services, known as built-in services, in your flow.

A transaction context starts when the pub.art.transaction:startTransaction service is executed. The transaction context is completed when either the pub.art.transaction:commitTransaction or pub.art.transaction:rollbackTransaction service is executed. As with implicit transactions, a single transaction context can contain any number of XA_TRANSACTION connections but no more than one LOCAL_TRANSACTION connection. If you choose to provide dynamic user credentials at run time, then all the adapter services using the LOCAL_TRANSACTION connection within a single transaction must use the same user credentials. For example, if you have two adapter services s1 and s2 configured using the LOCAL_TRANSACTION connection c1 in a single transaction context, then both s1 and s2 must either use the same dynamic credentials at run time or the default configured credentials provided at design time.

For more information on dynamic user credentials for a service's associated connection, see Changing the User Credentials of a Service's Associated Connection at Run Time.

A new explicit transaction context can be started within a transaction context, provided that you ensure that the transactions within the transaction context are completed in the reverse order they were started-that is, the last transaction to start should be the first transaction to complete, and so forth.

For example, the following is a valid construct:

The following example shows an invalid construct:

For explicit transaction examples, see Implicit and Explicit Transaction Examples.

For more information about designing and using flows, see the webMethods Service Development Help for your release.

For more information about transaction types, see Transaction Management of Adapter Connections.