Thursday, July 08, 2004

A Guideline to Transaction Management in J2EE Applications Transactions are always a vital part of everybody's life .. Transactions are involved when we withdraw some money using an ATM or buy a mocha from the Starbucks or shop at Amazon.com. However most java developers misunderstand transactions and its impact on performance and robustness of J2EE applications. We (Greg Pavlik and Jon Maron beside myself) had a fairly well-attended (cannot expect more than 40 people at 10:30pm) BOF: Transaction Management in J2EE - A Close Look in the JavaOne conference. Greg and Jon are co-authors of a recently published book Java Transaction Processing: Design and Implementation In this BOF presentation, we provided a background on transaction processing , programming model in Java and J2EE and a set of best practices for transaction management in J2EE applications. Several attendees asked me to send the best practices slides to them. In this article, I will outline the guidelines we provided to the J2EE Developers. None of these practices are new and often followed by most developers, however this is an attempt to outline all transaction related best practices together. Programmatic Transactions  If consistency is more important than performance access databases within the scope of a transaction. For example: UserTransaction ut = ctx.getUserTransaction (); ut.begin();  ic = new InitialContext (); remoteDS = (DataSource)ic.lookup ("java:comp/env/jdbc/OracleCMTDS"); Connection remoteConn = remoteDS.getConnection ("SCOTT", "TIGER"); // Perform database Operations ut.commit();   ŸAvoid using TransactionManager and XAResource interfaces. Instead use UserTransaction interface for transaction management Do not catch and handle javax.transaction.SystemException. If you catch this exception always Re-throw a RuntimeException ŸDo not catch RuntimeException in J2EE apps ŸAvoid using RuntimeException subtypes for application exceptions Declarative Transactions ŸUse  declarative transactions if possible because transaction is –Managed by container –Less coding Less Error prone ŸUse only Required, RequiresNew for CMP entity beans. ŸMDBs support only NotSupported and Required ŸWrap entity bean method calls with a Session façade to keep all the method calls in the same transaction. Transactions and Performance ŸEntity beans load/store data at transaction boundaries –Transaction settings affect how often database is accessed –Poor performance can be caused by transaction settings ŸRules of thumb –Always use REQUIRED for entity bean methods –Cover the unit of work in from the SessionFacade with a REQUIRED transaction Isolation Levels ŸAvoid setting transaction isolation level at the bean level –Set in the database level ŸUse the lowest isolation you can use for better performance ŸDo not change the isolation level within a transaction –Some databases will force a commit if you attempt to change the isolation level. Distributed Transactions ŸUse distributed transactions only when required ŸUse transaction propagation between multiple containers only when required ŸAvoid Last resource commit optimization if you need recovery in your application ŸAvoid using client-side demarcation To summarize, transactions are important for J2EE applications and improper use may lead to poor performance and incosistent data. 2:13:42 PM    comment []

© Copyright 2004 Debu Panda.

PS: These are my own thoughts and not of my employer ..