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, multiple SQL statements to a relational database are committed atomically by the database during the processing of an SQL COMMIT statement. 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).
The way that applications use transactions depends on the type of application component, as follows:
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 other OTS 1.2 compliant transaction managers (for example J2EE 1.3 application servers). WebSphere applications can also be configured to interact with databases, JMS queues, and JCA connectors through their local transaction support when distributed transaction coordination is not required.
In addition to supporting the coordination of XAResource-based resource managers, WebSphere Application Server for z/OS V5 supports the coordination of resource managers through RRS (z/OS resource recovery services). RRS-compliant resource managers include DB2, MQSeries, IMS, and CICS. IBM WebSphere Application Server for z/OS is capable of coordinating 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.
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.
Under normal circumstances you 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:
Last participant support (of WebSphere Application
Server Enterprise) 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.
The ActivitySession service (of WebSphere
Application Server Enterprise) 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 J2EE programming model. EJBs 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 through
its LocalTransaction interface for the period of a client-scoped ActivitySession
rather than just the duration of an EJB method.