Transaction in Web Tier • A servlet/JSP can use JNDI to lookup a UserTransaction and use JTA to demarcate transactions. • A transaction should not span multiple web requests. • In multi- tier environment using EJB, use of JTA in the Web tier is not recommended.
Ideally all transaction management should occur in the EJB Tier, whether Container managed or Bean managed. Then a change to transaction management is necessary, such as increasing timeout value, no code in the presentation layer will need to be changed. Furthermore, if you use Container managed transactions you will only have to change a line or two in your deployment descriptors and redeploy the EJB. Most Application Server support these types of changes without having to bounce the Server (hot deployment) as long as the interfaces for the EJB have not changed. There are times to break all rules, sometimes it is much easier to control a transaction from the client tier (in this case Web Tier). While these options should not be ignored, they should also not be abused because they negatively affect maintainability for the application.
As per J2EE Blueprints, here is the explanation: In a multitier environment, servlets and JSP pages's primary responsibilities are data presentation and user interaction, which are usually not transactional. Because transactions tend to be associated with business logic, database access and other transactional work should be handled by transactional enterprise beans, instead of by JTA in the Web tier. In designs that do not use enterprise beans, or where for some reason you choose to use Web-tier transactions, the following guidelines apply. JTA transactions, threads, and JDBC connections have many complex and subtle interactions. Web components should follow the guidelines stated in the transaction management chapter of the J2EE specification (version 1.3, section J2EE.4.1.4): JTA transactions must be started and completed only from the thread in which the service method is called. If the Web component creates additional threads for any purpose, these threads must not attempt to start JTA transactions. These additional threads will not be associated with any JTA transaction. JDBC connections acquired and released by threads other than the service method thread should not be shared between threads. JDBC Connection objects should not be stored in static fields. For Web components implementing SingleThreadModel, JDBC Connection objects may be stored in class instance fields. By definition, only one thread can ever access an instance of a Web component implementing SingleThreadModel; therefore, that instance can assume that fields that reference any JDBC connections, and those connections' transaction contexts, will not be shared with any other thread. For Web components not implementing SingleThreadModel, JDBC Connection objects should not be stored in class instance fields, and should be acquired and released within the same invocation of the service method.
posted 17 years ago
Thanks Srinivas. Althought I didn't understand exactly what you said, I got some idea.
There’s no place like 127.0.0.1. But I'll always remember this tiny ad: