Transaction support in WebSphere Application Server

Support for transactions is provided by the transaction service within WebSphere Application Server. The way that applications use transactions depends on the type of application component.

A transaction is unit of activity, within which multiple updates to resources can be made atomic (as an indivisible unit of work) such that all or none of the updates are made permanent. For example, during the processing of an SQL COMMIT statement, the database manager atomically commits multiple SQL statements to a relational database. In this case, the transaction is contained entirely within the database manager and can be thought of as a resource manager local transaction (RMLT). In some contexts, a transaction is referred to as a logical unit of work (LUW). If a transaction involves multiple resource managers, for example multiple database managers, an external transaction manager is required to coordinate the individual resource managers. A transaction that spans multiple resource managers is referred to as a global transaction. WebSphere Application Server is a transaction manager that can coordinate global transactions, can be a participant in a received global transaction, and can also provide an environment in which resource manager local transactions can run.

The way that applications use transactions depends on the type of application component, as follows:

• A session bean can use either container-managed transactions (where the bean delegates management of transactions to the container) or bean-managed transactions (component-managed transactions where the bean manages transactions itself).

• Entity beans use container-managed transactions.

• Web components (servlets) and application client components use component-managed transactions.

WebSphere Application Server is a transaction manager that supports the coordination of resource managers through their XAResource interface, and participates in distributed global transactions with transaction managers that support the CORBA Object Transaction Service (OTS) protocol or Web Service Atomic Transaction (WS-AtomicTransaction) protocol. WebSphere Application Server also participates in transactions imported through Java EE Connector 1.5 resource adapters. We can also configure WebSphere applications to interact with databases, JMS queues, and JCA connectors through their local transaction support, when we do not require distributed transaction coordination.

(zos) In addition to supporting the coordination of XAResource-based resource managers, WebSphere Application Server for z/OS supports the coordination of resource managers through RRS (z/OS resource recovery services). RRS-compliant resource managers include DB2 , WebSphere MQ, IMS™, and CICS . IBM WebSphere Application Server for z/OS can coordinate a mix of RRSTransactional resource managers and XA capable resource managers under the same global transaction.

(zos) Resource managers that offer transaction support can be categorized into those that support two-phase coordination (by offering an XAResource interface or by supporting RRS) and those that support only one-phase coordination (for example through a LocalTransaction interface). The WebSphere Application Server transaction support provides coordination, within a transaction, for any number of two-phase capable resource managers. It also enables a single one-phase capable resource manager to be used within a transaction in the absence of any other resource managers, although a WebSphere transaction is not necessary in this case.

Resource managers that offer transaction support can be categorized into those that support two-phase coordination (by offering an XAResource interface) and those that support only one-phase coordination (for example through a LocalTransaction interface). The WebSphere Application Server transaction support provides coordination, within a transaction, for any number of two-phase capable resource managers. It also enables a single one-phase capable resource manager to be used within a transaction in the absence of any other resource managers, although a WebSphere transaction is not necessary in this case.

Under normal circumstances, we cannot mix one-phase commit capable resources and two-phase commit capable resources in the same global transaction, because one-phase commit resources cannot support the prepare phase of two-phase commit. There are some special circumstances where it is possible to include mixed-capability resources in the same global transaction:

• In scenarios where there is only a single one-phase commit resource provider that participates in the transaction and where all the two-phase commit resource-providers that participate in the transaction are used in a read-only fashion. In this case, the two-phase commit resources all vote read-only during the prepare phase of two-phase commit. Because the one-phase commit resource provider is the only provider to complete any updates, the one-phase commit resource does not have to be prepared.

• In scenarios where there is only a single one-phase commit resource provider that participates in the transaction with one or more two-phase commit resource providers and where last participant support is enabled. Last participant support enables the use of a single one-phase commit capable resource with any number of two-phase commit capable resources in the same global transaction. For more information about last participant support, see Use one-phase and two-phase commit resources in the same transaction.

The ActivitySession service provides an alternative unit-of-work (UOW) scope to that provided by global transaction contexts. It is a distributed context that can be used to coordinate multiple one-phase resource managers. The WebSphere EJB container and deployment tooling support ActivitySessions as an extension to the Java EE programming model. Enterprise beans can be deployed with lifecycles that are influenced by ActivitySession context, as an alternative to transaction context. An application can then interact with a resource manager for the period of a client-scoped ActivitySession, rather than only the duration of an EJB method, and have the resource manager local transaction outcome directed by the ActivitySession. For more information about ActivitySessions, see Use the ActivitySession service.

(zos) We can use transaction classes to classify client workload for workload management. The workload is different WebSphere transactions targeted to separate servant regions, each with goals defined by appropriate service classes. Each transaction is dispatched in its own WLM enclave in a servant region process, and is managed according to the goals of its service class. The server controller, which workload management views as a queue manager, uses the enclave associated with a client request to manage the priority of the work. If the work has a high priority, workload management can direct the work to a high-priority servant in the server. If the work has a low priority, workload management can direct the work to a low-priority servant. The effect is to partition the work according to priority within the same server.

Subtopics

• Resource manager local transaction (RMLT)
  A resource manager local transaction (RMLT) is a resource manager view of a local transaction; that is, it represents a unit of recovery on a single connection that is managed by the resource manager.

• Global transactions
  If an application uses two or more resources, an external transaction manager is needed to coordinate the updates to all the resource managers in a global transaction.

• Local transaction containment
  A local transaction containment (LTC) is used to define the application server behavior in an unspecified transaction context.

• Local and global transactions
  Applications use resources, such as JDBC data sources or connection factories, configured through the Resources view of the console. How these resources participate in a global transaction depends on the underlying transaction support of the resource provider.

• Client support for transactions
  Application clients can, within certain limits, support the use of transactions.

• Commit priority for transactional resources
  We can specify the order in which transactional resources are processed during two-phase commit processing.

• (dist)(zos) Share locks between transaction branches
  We can specify that multiple application components on different application servers can share access to data in a single DB2 database under the same global transaction. You specify that the different transaction branches share locks under the global transaction.

• Transactional high availability
  The high availability of the transaction service enables any server in a cluster to recover the transactional work for any other server in the same cluster. This facility forms part of the overall WebSphere Application Server high availability (HA) strategy.

• Transaction compensation and business activity support
  A business activity is a collection of tasks that are linked together so that they have an agreed outcome. Unlike atomic transactions, activities such as sending an email can be difficult or impossible to roll back atomically, and therefore require a compensation process in the event of an error. The WebSphere Application Server business activity support provides this compensation ability through business activity scopes.

• JTA support
  Java Transaction API (JTA) support provides APIs in addition to the UserTransaction interface defined in the JTA 1.1 specification.

• (dist)(zos) SCA transaction intents
  Service Component Architecture (SCA) provides declarative mechanisms in the form of intents for describing the transactional environment required by components.

Related concepts

(zos) Resource Recovery Services (RRS)

Coordination of access to one-phase commit and two-phase commit capable resources in the same transaction

The ActivitySession service

Transaction troubleshooting tips

Related information:

The Java transaction service (JTS)
The Java transaction API (JTA)
Web Service Atomic Transactions (WS-AtomicTransactions) specification
Java EE Connector Architecture
CORBA Object Transaction Service (OTS)