Intel 170 Servers, AS/400 RISC Server, 7xx Servers manual

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:

yYour application must use the assured persistent reliability attribute for its JMS messages.

yYour 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