Stateful UI Transactions


J2EE patterns: Stateful UI Transactions

  1. Stateful UI Transactions (10 messages)

    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 {
    } catch (Exception e) {

    transaction – handle to transaction example, javax.transaction.UserTransaction or java.sql.Connection
    This ensures that all tasks are either committed or rolled back, with the help of Transaction Service Provider.


    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.


    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+ Specification Version 2 – page 9]. Most application servers hence implement transactions as a Thread Local Entity.

    Now we need to ensure that, the thread that started transaction and executed Task 1 and 2, should execute Task 3 and commit /rollback the transaction.

    The pattern models a logical TransactionContext (Object diagram - , nothing but a Java Thread that begins/commits/rolls back a transaction and executes transactional activities. Client threads assign tasks to the threads executing transactional activities.

    Additional thoughts:

    Further, application may require to LOCK the data while user interaction. This can be achieved using ISOLATION LEVELS set on connections used to access/modify the data.

    Reference Implementation:

    I have tried putting together this pattern as a portable framework ( Would like to receive comments on the same.

    Dnyanesh Y. Sonavane
  2. Object Diagram:-
    Ref Impl:-
  3. Have a look to Spring's transaction abstraction. I'd say it's pretty good :-)
  4. Still the links are not accessible. Getting Forbidden error

  5. Dorel Vaida,

    transaction absn in spring framework is excellent, it separates transaction handling from the data sources like JDBC1.1, JDBC2.0 DataSource. Even you can have wrapper over JTA. But spring framwork extends basic concept of "thread of execution" (refer to Page 79, spring-reference.pdf). This means the following call will return the current active transaction
    TransactionStatus status = transactionManager.getTransactionDefinition(def);
    and hence the callback
    public Object doInTransaction(TransactionStatus status);
    will be executed in the current active transaction.

    The problem we want to solve is different, we want to maintain transaction across user interactions and this is possible if we execute transactional tasks in same thread. Hope this helps.


    Please check following link

  6. There is another way[ Go to top ]

    What happens when the user does not call method3() and simply closes the browser? How is the pending transaction rolled back?

  7. Re: There is another way[ Go to top ]

    If the user closes the browser , the transaction can be rolled back, if we set a transaction timeout. You can set the timeout in spring.
  8. Workflow software[ Go to top ]

    It might be better to let a workflow type software with support for rollbacks handle all this for your application rather than thinking of it in database terms.
  9. Pratha,

    Transaction will be timed out by transaction manager, if method3() is not called at all and the Thread representing the transaction can be returned back to the Pool.

    Archimedes Trajano,

    You are right. I am implementing this pattern for a Workflow manager in Java.
  10. When implementing this as a workflow management system, you will soon be dealing with long running transactions involving interaction with different (possibly dislocated) systems and platforms and user interaction. Find out what you can about long running transactions, for instance by reading on the subjects related to bpel and ws-businesstransaction, which will give you a good idea on the forces you are dealing with here.
    Some where down the line you will have to implement compensating transaction support for all transactional parties, simply because you cannot allways keep the actual transaction (time-outs, unavailability of resources or users, etc)

    Good luck
    Jan Kopmels
  11. Hibernate suggests the usage of session per conversation pattern. I dont know, if we can use this for the workflow scenario. you can search "hibernate session and transactions" in google, to read about it. for ppl who have read that - -if we set the flushmode = NEVER for the session, and lets say we open a long running session. user submits a form on page1 -open a session -begin transaction(set isolation, propagation) execute task1 -end transaction we write a response back to the user, showing page 2 user submits page2 -begin transaction(set isolation, propagation) execute task2 -end transaction -flush session -close session The above is my understanding of session perconversation usage. now lets say task2 fails, if we do not flush the session, could it be equivalent of rolling back both the transactions? Rajesh