EJB design: MVC - Transaction management
In most of the MVC applications (web) the transaction management is handled by the controller. The transaction gets committed or rolled back after executing the business logic and before the request is forwarded to the view. What happens if an error occurs when processing the view (JSP)? The client will not get the proper page and he has no way of knowing what happened to the posted transaction. Is there an efficient way to extend the transaction till the view gets processed?
- Posted by: Ashokkumar T.A
- Posted on: April 02 2004 01:28 EST
I have seen this happening on Indian Railways online reservation site. After you have paid the amount through credit card and then if you see any error (like NullPointerException) in jsp while showing the output, you have no way to know whether this error is generated while sending the request or while generating the output.
It is difficult in such cases to know whether the trasaction was successful or not.
Extending the transaction till the sucessful view generation is not advisable.
Instead we can keep the final view as simple as possible so that chances of error in this final view are minimum.
Can struts framework's error page defined struts-config.xml for this confirmation action will be useful in this case ??
I can see three solutions in increasing complexity:
1. Use a Filter in your webapp that starts and ends the transaction. A sample filter is included in Atomikos' TransactionsJTA for Tomcat:
http://www.atomikos.com/products/transactionsJTA/overview.html (developer licenses are free).
2. Another way: within the scope of your transaction, post a JMS message that gets processed by an email daemon (and sends a confirmation email to the user).
Users will get confirmation of committed txs.
3. Yet another way: code your application so that users can get an overview of business transactions they did in the recent past. If an error happens, they can still come back and check.
Here is another solution:
Problems like this tend to arise because the controller action and the view are incorporated into the same HTTP request, with the controller using request.forward() to invoke the view.
If you use a client-side redirect to invoke the view, response.sendRedirect(), the controller operation and the view operation are completely separate, and you can tell which errors caused what.
This also solves a number of other problems, most notably what I call the "reload problem", which happens when the user reloads the resulting view page, and accidently re-executes the action because action/view are encoded in the same URL.