       |  |
Integration Manager Enterprise Server User
CHAPTER 5
Integration Manager applications that perform transactions require special planning and deployment. Runtime and deployment issues associated with transaction management are covered in this chapter. For a discussion of design-time issues, such as how to use the Transaction Action, see the chapter on Advanced Actions in the Integration Manager User's Guide.
In Integration Manager, the Transaction action can call any of the defined Java Transaction API (JTA) server-side transaction commands. For example:
The begin, commit, and rollback commands are available for use in projects that will be deployed as servlets or EJBs with bean-managed transaction behavior.
The Set Rollback Only command is available for use in projects that will be deployed as container-managed EJBs.
These choices, appropriately enabled/disabled, are available from the Transaction dialog (see below), which appears when you create a new Transaction Action in Integration Manager.
As described in an earlier chapter, Integration Manager services can be front-ended by servlets, EJBs, or arbitrary Java classes. Each mechanism has important implications for transaction control, as a result of the way transactions are defined in the Java Transaction API (JTA).
Servlet deployment using JDBC connection pools are recommended when complex transactional behavior is not required, such as inquiry-only services. The primary limitations of Servlet deployments are:
Declarative transaction control is not allowed. If this is a requirement, use an EJB deployment instead.
JDBC connections from the connection pool destined for a Servlet are by default set with auto-commit turned on. This means that after each Update, Delete, or Insert statement, the transaction is automatically committed to the database. Subsequent rollbacks will have no effect. There are two ways to change this behavior:
1. Issue a Begin Transaction command (using a Transaction action), and utilize a subsequent Commit or Rollback command as appropriate.
2. Check the "Allow SQL Transactions" checkbox for the connection. See JDBC Transaction Control: Allowing User Transactions for further details.
NOTE: Nested transactions are not allowed, but sequential ones are.
Deploying Integration Manager services as EJBs gives the maximum transaction management flexibility. EJBs are the recommended deployment choice if your application requires a distributed transaction environment where data has to be updated in a number of back end systems. Before examining specifics for EJB Deployment, it is worthwhile to review the deployment options regarding transactions as indicated in the EJB specification. The following definitions are helpful:
Application is the user of the transaction services, normally the EJB.
Container is the application server provided context in which an EJB is deployed to and executes.
Resource Manager is the interface to the back end system, such as a database or a message queue.
Resource Adapter is the interface to the Resource manager, such as a JDBC driver.
Transaction Manager is an application server provided object that controls the flow of the transaction, setting up the transaction between all players. This normally involves mapping the high level calls to low level transaction calls to the standard X/Open XA protocol.
See the accompanying illustration.
All container-managed transactions are on a method call basis, while stateful Bean-managed transactions may span method calls. The EJB literature sometimes implies that with EJBs, all transaction management is done behind the scenes and is of no concern to the application developer. Although complex two-phase commit logic is, in fact, performed automatically (and rollbacks will automatically occur if exceptions are thrown), developers still need to have an understanding of how EJB transactions are managed in order to ensure desired application results.
When an EJB is deployed as a Bean-managed transaction, it is expected to communicate with the transaction manager indirectly via a simplified transaction interface called UserTransaction. UserTransaction provides transactional commands such as begin, commit, and rollback. These commands are only available to the Bean if it is deployed as Bean-managed. If they are issued when the EJB is deployed as Container-managed, an IllegalStateException is thrown. Consequently, developers need to know in advance how the Bean is going to be deployed.
Container-managed Transaction demarcation, also known as declarative transaction support, is a powerful and flexible means for transaction support. The application assembler is free to determine the EJB's transactional behavior post construction. Container-managed transactions are most useful in cases where EJBs utilize other EJBs to get work done. The classic example of this case is a stateless Session Bean calling several Entity Beans to update various tables in a database. Linking their transaction via declarative transaction management greatly reduces the complexity of the code, as any failure in any of the components can automatically roll back the transaction.
EJBs support six different Container-managed transaction types. The most important differentiator among the six is the notion of transaction propagation. If one EJB with an ongoing transaction calls another, the transaction may or may not be passed along to the second EJB. If it is passed, and the transaction is subsequently rolled back, then all work done in all EJBs within the scope of that transaction are rolled back.
Container-managed transaction types include:
In Container-managed transactions, there is no way to call any type of commit. The user can initiate a rollback by calling the setRollbackOnly() method on the EJB context. This call is only appropriate in certain situations, however. If the application is deployed as a Bean-managed EJB, or a Container-managed EJB without Transaction support, a call to setRollbackOnly() will result in a java.lang.IllegalStateException.
Container-managed transactions are a very powerful mechanism to perform complex transaction management in a heterogeneous environment. Such a complex distributed environment requires support from the back end resource manager, the middleware drivers, and the application server.
NOTE: At this time, the Novell exteNd Application Server supports distributed transaction management across connections from a single connection pool. Check with the appropriate vendor's documentation if you are using a server other than Novell exteNd Application Server.
Check that you are using an XA-enabled database driver before using transactions involving database access. Most vendors provide XA and non-XA version of their drivers. If you are not able to use an XA-aware driver, you may still be able to enlist JDBC components in transactions, but you should commence the transaction before opening the database connection (i.e., before calling the JDBC component). You should test this scenario, obviously, before relying on it.
EJB deployment is recommended in situations where complex transactional behavior is required. By default, the Deployment Wizard bases the deployment-mode choice on the current Transaction Emulation Mode (as set in Tools > Preferences, using the Designer tab). If the emulation mode you've chosen indicates a bean-managed EJB deployment, the Deployment Wizard will create this type of deployment. Otherwise, it will default to a Container-managed, "Transaction Not Supported" deployment. (One can easily change from Not Supported to Mandatory, Supports, Requires New, or any of the other valid choices for bean or Container-managed transactions using the pull-down menu in the Transaction Attribute field of the EJB-Based Service Triggers Panel of the Deployment Wizard.)
Manual control of transactions is sometimes required. For such situations, Integration Manager has a special checkbox on the JDBC connection component that allows user-controlled SQL transactions.
NOTE: This is an advanced option, and should only be used if you are comfortable with the details of SQL programming.
Checking the Allow SQL Transactions box does the following:
It translates all SQL commit and rollback commands to the equivalent JDBC connection calls
It causes Integration Manager Enterprise Server to perform a rollback on the JDBC connection if the last Execute SQL Action in the JDBC component was not a commit or a rollback.
NOTE: This behavior is important if connection pools are used. When you return a connection to the pool, the pool manager expects to be handed a "clean" connection. If you return a dirty connection (a connection with uncommitted changes on it), undesirable results, such as table locking and transaction scope mismatches, can occur. To prevent this, Integration Manager detects a dirty connection, and attempts to clean it by issuing a rollback, unless the user has explicitly commanded a commit. Bottom line: It is vitally important that you explicitly issue a commit (with a Transaction Action) at the end of the JDBC component action model, after all database operations have completed, if your transactionable logic executed without error.
It restores the state of the autocommit flag at the end of the transaction immediately before returning the connection back to the pool
If you check the Allow SQL Transactions box, Novell recommends that you deploy your Integration Manager service either as a conventional servlet-triggered service, or as an EJB in the Container-managed, "Not Supported" transaction mode. In addition, we strongly recommend that you issue a commit or a rollback as the last SQL statement in your JDBC component. A "best practice" would be to wrap the entire JDBC component action model in a Try/On Fault block to catch any exceptions.
NOTE: As database drivers may react differently, be sure to test your application in a deployed state to verify the desired transactional behavior.
EJB home page: http://java.sun.com/products/ejb
JTA home page: http://java.sun.com/products/jta
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...