Background: Atomicity is one of the mandatory requirements of transactional applications It is about executing all or nothing, hence most of the times application defines transaction boundaries like, try {transaction.begin (); executeTask1 (); executeTask2 (); executeTask3 (. ); transaction.commit ();} catch (Exception e) {transaction.rollback ();} transaction - handle to transaction example, javax.transaction.UserTransaction or java.sql.ConnectionThis ensures that all tasks are either committed or rolled back , with the help of Transaction Service Provider Problem:. Let us first understand the meaning of "Stateful UI Transactions" (I know the nomenclature is confusing enough, but I could not think of anything else) .What if, executing Task 3 (referring to the snippet above) requires manual interference / decision? (Operator wants to validate availability of seats before reserving one). One has to maintain the transaction state across user interactions. In a typical commercial application this would be a Web based GUI or a Windows based client.Solution:. There can be multiple solutions, database design should consider such a requirement and define flags to indicate transaction status However, these solutions couple the requirement and data base design tightly.Other solution that comes into mind is to store the Transaction handle in Session (Either HTTP or Custom Session) and reuse across user interaction to define transaction boundaries. This will not solve our problem, as a transaction handle is always a stateless wrapper over the actual transaction managed by transaction service Provide (An Application Server) .as Recommended A Thread of Execution Realizes a Transaction. [Ref: Distributed Transaction Processing: The Xa
