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.
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. You can also configure WebSphere applications to interact with databases, JMS queues, and JCA connectors through their local transaction support, when you do not require distributed transaction coordination.
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.
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.
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 Using the ActivitySession service.
You 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.