Transaction management under J2EE 1.2

Explore your options for managing transactions

1 2 Page 2
Page 2 of 2
  • Multiple database connections within a transaction context and the two-phase commit protocol: The J2EE 1.2 specification does not require a J2EE server implementation to support access to multiple JDBC databases within a transaction context (and support the two-phase commit protocol). The javax.transaction.xa.XAResource interface is a Java mapping of the industry-standard XA interface based on X/Open CAE specification. (See Resources.) X/Open is a consortium of vendors who aim to define a Common Applications Environment that supports application portability. Support for the multiple JDBC data sources, javax.transaction.xa.XAResource, two-phase commit, etc., is optional in the current specification, though the next version will likely mandate such support. Sun Microsystems's J2EE reference implementation, for instance, supports access to multiple JDBC databases within the same transaction using the two-phase commit protocol.
  • Transactional support for application clients and applets: The J2EE 1.2 specification does not require that transactional support be made available to application clients and applets. Some J2EE servers may provide such support in their J2EE server products. As a design practice, transaction management within application clients should be avoided as much as possible, in keeping with the thin client and three-tier model. Also, a transaction, being a precious resource, must be distributed sparingly.
  • Inter-Web-component transaction context propagation: The J2EE 1.2 specification does not mandate that the transaction context be propagated between Web components. Typically, Web components like servlets and JSPs need to make calls on (session) EJB components, rather than to other Web components.

Transactional support and portability

In the interest of component portability, it is important for you -- the designer and developer -- to understand which aspects of transactional support are mandatory and which are optional. In the J2EE model, components are written against a specification and are meant to be deployed on J2EE-compliant application servers from various vendors -- all in the interest of protecting IT investment and cross-J2EE-server portability. But if a crucial transactional functionality needs an optional transactional feature, take adequate care to declare, document, and highlight the dependency clearly, explicitly, and as early as possible.

Conclusion

J2EE's declarative transaction demarcation approach is more elegant than programmatic transaction demarcation. At the same time, using declarative transaction demarcation means relinquishing control of the isolation level, since one is limited to the default level provided in the DBMS. If you must use programmatic transaction demarcation, JTA transactions are generally preferred over JDBC transactions. JTS transactions, however, cannot be nested. In the interest of portability, be aware of the optional and mandatory aspects of transactional support in the J2EE platform. Against this background, your application's specific transactional needs will naturally govern your choice of transaction management strategy.

Sanjay Mahapatra is a Sun Certified Java programmer (JDK 1.1) and architect (Java Platform 2). He currently works for Cook Systems International, a consulting and systems integration vendor for the Java 2 Platform.

Learn more about this topic

1 2 Page 2
Page 2 of 2