Using this support, you can build a J2EE application to group a set of changes into one transaction, or a single unit of work, so that all changes within a transaction are either fully completed or fully rolled back. This enables your application to run in a J2EE-compliant application server (for example, WebSphere® Application Server) to access IMS transactions and data in a coordinated manner. Global transaction management ensures the integrity of the data in IMS.
When you make changes to your protected resources, you want to guarantee that the changes are made correctly. For example, as a bank customer you want to transfer money from your savings account to your checking account. You want to be sure that when the money is deducted from your savings account it is added to your checking account simultaneously. You would not want this transaction to be completed only partially with the money deducted from your savings account but not added to your checking account.
In another example, you need to buy a ticket from San Francisco to Paris but a direct flight is not available. Unless you can successfully reserve a ticket from San Francisco to Chicago and another ticket from Chicago to Paris, you will not commit to your trip to Paris. That is, you will "roll back" your decision to go to Paris because having a confirmed seat for only one part of your trip is not useful to you.
In both of these examples, several smaller transactions are required in order to complete one overall transaction. If there is a problem with one of these smaller transactions, you would not want to commit the overall transaction (such as transferring money or going to Paris). Instead, you would want to roll back every step of the transaction so that none of the smaller transactions are committed. To transfer your money or to go on your trip to Paris successfully, you want the smaller transactions to be managed and coordinated together to complete the overall transaction.
To ensure a coordinated transaction process, the J2EE platform (which consists of a J2EE application server, J2EE application components, and a J2EE connector architecture resource adapter) provides a distributed transaction processing environment where transactions are managed transparently and resources are updated and recovered across multiple platforms in a coordinated manner.
A J2EE-compliant application server (such as WebSphere Application Server) uses a Java™ transaction manager, also known as an external coordinator, to communicate with the application components (for example, Java servlets or Enterprise Java Beans) and the resource managers (for example, IMS or DB2®) through the resource adapters (for example, the IMS TM resource adapter) to coordinate a transaction.
If a transaction manager coordinates a transaction, that transaction is considered a global transaction. If a transaction manager coordinates a transaction with more than one resource manager, the external coordinator uses two-phase commit protocol.
In the previous bank example, you want to transfer money from your savings account to your checking account. If your savings account information resides on a separate resource manager from your checking account information (for example, your saving account resides on IMS and your checking account resides on DB2), the transaction manager in the application server (WebSphere Application Server) helps the application to coordinate the changes between IMS and DB2 transparently using two-phase commit processing. Specifically, the transaction manager works with the IMS resource adapter to coordinate the changes in IMS.
The IMS TM resource adapter is designed to work together with the Java transaction manager in the J2EE platform, the Resource Recovery Services (RRS) of z/OS®, and IMS Connect to make consistent changes to IMS and other protected resources.
To participate in two-phase commit processing with IMS, the IMS TM resource adapter uses the IMS OTMA Synchronization level sync-point protocol. To participate in global transaction and two-phase commit processing when the changes are requested from a remote application, IMS uses RRS on z/OS.
RRS, from the point of view of IMS, acts as the "external coordinator" or sync-point manager to coordinate the update and recovery of resources. The IMS TM resource adapter and IMS Connect, interact with the Java transaction manager running in the application server and RRS on z/OS to allow a global transaction running on a J2EE platform to participate in a coordinated update with IMS running on the host.
When setting up a J2EE application to participate in a global transaction, you must select one of the two available communication protocols to be used between IMS Connector for Java and IMS Connect. The two communication protocols supported by IMS Connector for Java and IMS Connect are TCP/IP and Local Option.
In a global transaction scope, your J2EE application component can access an IMS transaction by establishing a TCP/IP connection with IMS Connect. Underlying, the IMS TM resource adapter interacts with the Java transaction manager using the X/Open (XA) protocol to manage the global transaction and two phase commit processing. The XA protocol defines a set of interfaces and interactions describing how the Java transaction manager and the resource managers interact in a distributed transaction processing environment. The IMS TM resource adapter, together with IMS Connect, uses the XA protocol and works with IMS and Resource Recovery Services (RRS) on z/OS to make consistent changes.
Restrictions: You are required to have RRS running on the same MVS™ system with IMS Connect.
To set up RRS on IMS Connect, refer to IMS Connect Guide and Reference (SC27-0946). For more information about TCP/IP communication protocol for global transaction and two-phase commit processing, see Platform considerations and communication protocol considerations and Two-phase commit environment considerations.
If your J2EE application component is running on WebSphere Application Server for z/OS, you can submit IMS transaction messages using Local Option and participate in global transaction processing. This transaction processing is coordinated by Resource Recovery Services (RRS) on z/OS and WebSphere Application Server for z/OS. IMS Connector for Java is RRS-compliant and is designed specifically to work with RRS so that the Java transaction manager in WebSphere and IMS, as the resource manager, can work together to make consistent changes to multiple protected resources. The XA protocol is not used by the IMS TM resource adapter when running global transaction with Local Option.
For information about Local Option communication protocol for global transaction and two-phase commit processing, see Platform considerations and communication protocol considerations, Two-phase commit prerequisites, and Two-phase commit environment considerations.
Local Transaction
The J2EE Connection Architecture defines the javax.resource.cci.LocalTransaction interface to allow a resource manager, rather than a transaction manager, to coordinate a transaction locally. However, the IMS TM resource adapter only supports transaction coordination with a transaction manager. Thus, IMS Connector for Java does not support the javax.resource.cci.LocalTransaction interface. If you call the IMSConnection.getLocalTransaction() method you will get a NotSupportedException. To use transaction support with the IMS TM resource adapter, you need to either use the JTA transaction interface, or set an appropriate transaction attribute in the deployment descriptor in your application. See Using global transaction support in your application for more information.
One-phase commit processing
The IMS TM resource adapter supports one-phase commit optimization with the transaction manager. As a result, if all changes inside a transaction scope belong to the same IMS resource, the transaction manager might perform one-phase-commit optimization such that the transaction manager sends the phase two commit request directly to the resource manager for committing the changes without sending the phase one prepare request.
Non-global transaction processing
If no global transaction processing is used in the application (for example, when the transaction attribute is set to TX_NOTSUPPORTED), all non-global transaction processing uses "Sync-On-Return" (OTMA SyncLevel=None). By the time the IMS transaction is committed, the output has been returned to the client.
Conversational transaction processing in global transaction scope
IMS uses a conversational program to divide processing into a connected series of client-to-program-to-client interactions (also called iterations). Each iteration is a type of IMS conversational transaction. Conversational processing is used when one transaction contains several parts. Each part that comprises one large transaction is separately committed or rolled back.
For more information about using global transaction support, see the IMS TM resource adapter web page at www.ibm.com/ims and go to Hints and Tips on the Support page.