Transaction over multiple pages?


Performance and scalability: Transaction over multiple pages?

  1. Transaction over multiple pages? (4 messages)

    When you have a series of web-pages and the last one of these, is a page where the user can confirm everything or cancel everything (link a wizard). If each of these pages is dealing with its own Entity EJB, how do I wrap the changes in a transaction? Have considered to keep track of the changes in the session (not updating the EJB's) and then if the user confirms at the last page, make the changes all in one. But then some new problems arises, how do I keep the information from request to request? If I keep them in the HTTP-session, what do I do if I one day wishes to cluster the application?

    Threaded Messages (4)

  2. Look at Struts[ Go to top ]

    Struts can keep forms across multiple requests -- you could then do a txn at the end...

  3. You can store the client interaction states in the HTTP session or a stateful session bean.

    If you use HTTP session and your web server load balancer supports sticky load balancing, then you are OK. Because all HTTP requests for the same session will end up with the same web server. If use HTTP session, it will only work for web clients.

    If you use SFSB, it depend upon how your clustered App Server deals with SFSB.

    Hope it helps.

  4. If I'm not mistaking, I cannot use SFSB without using HTTP-session, because where else should I keep the reference to my SFSB?

    Struts is unfortunately not an option for me, as I have to use a different framework.
  5. Transaction over multiple pages?[ Go to top ]

    THe best bet would be to keep the dat in the HTTP session. If that does not work (because of the specific deployment architecture that is used), then another option might be to persist the data to a small database that exists only to maintain such state information. This DB could be the same or different from the true application DB. This is a very heavy/brute approach, but it will work.