webMethods Adapter Runtime 10.7 | webMethods Adapter Runtime Documentation | webMethods Adapter Runtime User’s Documentation | Transaction Management | Explicit Transactions
 
Explicit Transactions
 
Explicit Transaction Usage Cases
You use explicit transactions when you need to manually control the transactional units of work. To do this, you use built-in services in your flow services.
An explicit 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. For information about the services, see Built-In Services for Transaction Management.
When you define an explicit transaction, it is nested within the implicit transactions that are controlled by the transaction manager. You can have more than one explicit transaction defined within an implicit transaction. You can also nest explicit transactions within each other.
As with implicit transactions, a single explicit 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, 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, 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 about providing 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. The last transaction to start should be the first transaction to complete, and so forth.
The following example shows a valid construct.
pub.art.transaction:startTransaction
   pub.art.transaction:startTransaction
      pub.art.transaction:startTransaction
      pub.art.transaction:commitTransaction
   pub.art.transaction:commitTransaction
pub.art.transaction:commitTransaction
The following example shows an invalid construct.
pub.art.transaction:startTransaction
   pub.art.transaction:startTransaction
pub.art.transaction:commitTransaction
   pub.art.transaction:commitTransaction
Note:
With explicit transactions, you must be sure to call either a commitTransaction or rollbackTransaction for each startTransaction. Otherwise, you will have dangling transactions that will require you to reboot Integration Server.
For more information about designing and using flows, see webMethods Service Development Help.