This section describes how webMethods Integration Server supports transactions. Integration Server considers a transaction to be one or more interactions with one or more resources that are treated as a single logical unit of work. The interactions within a transaction are either all committed or all rolled back. For example, if a transaction includes multiple database inserts, and one or more inserts fail, all inserts are rolled back.

Integration Server supports the following kinds of transactions:

Integration Server can automatically manage both kinds of transactions, without requiring the adapter user to do anything. Integration Server uses a container-managed (implicit) transaction management approach based on the JCA standard, and also performs some additional connection management. This is because adapter services use connections to create transactions. For more information, see Implicit Transaction Usage Cases.

However, there are cases where adapter users need to explicitly control the transactional units of work. Examples of these cases are provided in Explicit Transaction Usage Cases.

To support transactions, Integration Server relies on a built-in transaction manager. The transaction manager is responsible for beginning and ending transactions, maintaining a transaction context, enlisting newly connected resources into existing transactions, and ensuring that local and XAResource transactions are not combined in illegal ways.

Beginning with Integration Server 8.0, the Transaction Manager also manages operations performed by a transacted JMS trigger, or a built-in JMS service that uses a transacted JMS connection alias.

To specify which kind(s) of transactions to support in your adapter, see Specifying Transaction Support in Connections.