IBM 170 Servers Manual page 105

Performance Considerations When Using WebSphere Transaction Processing (XA)
In a general sense, a transaction is the execution of a set of related operations that must be completed
together. This set of operations is referred to as a unit-of-work. A transaction is said to commit when it
completes successfully. Otherwise it is said to roll back. When an application needs to access more than
one resource (backend) and needs to guarantee job consistency, a global transaction is required to
coordinate the interactions among the resources, application and transaction manager, as defined by the
XA specification.
WebSphere Application Server is compliant with the XA specification. It uses the two-phase commit
protocol to guarantee the All-or-Nothing semantics that either all the resources commit the change
permanently or none of them precede the update (rollback). Such a transaction scenario requires the
participating resource managers, such as WebSphere JMS/MQ and DB2 UDB, to support the XA
specification and provide the XA interface for a two-phase commit. It is the role of the resource managers
to manage access to shared resources involved in a transaction and guarantee that the ACID properties
(Atomicity, Consistency, Isolation, and Durability) of a transaction are maintained. It is the role of
WebSphere Transaction manager to control all of the global transaction logic as defined by the J2EE
Standard. Within WebSphere there are two ways of using WebSphere global transaction: Container
Managed Transaction (CMT) and Bean Managed Transaction (BMT). With Container Managed, you do
not need to write any code to control the transaction behavior. Instead, the J2EE container, WebSphere in
this case, controls all the transaction logic. It is a service provided by WebSphere.
When your application involves multiple resources, such as DB2, in a transaction, you need to ensure that
you select an XA compliant JDBC provider. For WebSphere on the System i platform you have two
options depending on if you are running in a two tier environment (application server and database server
on the same system) or in a three tier environment (application server and database server on separate
systems). For a two tier environment you would select DB2 UDB for iSeries (Native XA - V5R2 and
later). For a three tier environment you would select DB2 UDB for iSeries (Toolbox XA).
However, since the overhead of running XA is quite significant, you should ensure that you do not
configure an XA compliant JDBC provider if your application does not require XA functionality. In this
case, in a two tier environment you would select DB2 UDB for iSeries (Native - V5R2 and later) and for
a three tier environment you would select DB2 UDB for iSeries (Toolbox).
In WebSphere 6.0 the JMS provider was totally rewritten. It is now 100% pure Java and it no longer
requires WebSphere MQ to be installed. Also, the datastore for the messaging engine can be configured to
store persistent data in DB2 UDB for iSeries. As a result, you can configure your application to share the
JDBC connection used by a messaging engine, and the EJB container. This enables you to use one-phase
commit (non-XA) transactions since you now have only one resource manager (DB2) involved in a
transaction. Previously with 5.1 you had to use XA since the transaction would involve MQ and DB2
resource managers. By utilizing one-phase commit optimization, you can improve the performance of
your application.
You can benefit from the one-phase commit optimization in the following circumstances:
Your application must use the assured persistent reliability attribute for its JMS messages.
Your application must use CMP entity beans that are bound to the same JDBC data source that the
messaging engine uses for its data store.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 6 - Web Server and WebSphere 105