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 Connector Architecture standard, and also performs some additional connection management because adapter services use connections to create transactions. For more information about implicit transactions, see Implicit Transactions.

However, there are cases where you need to explicitly control the transactional units of work. For more information about explicitly managing transactions, see Explicit Transactions.

To support transactions, Integration Server relies on a 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.

The transaction manager only manages operations performed by adapter services, a transacted JMS trigger, or a built-in JMS service that uses a transacted JMS connection alias. Since the transaction manager cannot manage operations performed by any other service, a commit or rollback is not applicable for operations performed by those services.