This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am hoping to create a customer registration application which will involve 4 sequence of JSP pages. Each page will associate with Relational Table and in order to complete the registration a user should follow all e JSP pages. If user has interrupted the registration half way it should rollback from database tables. I have quite a few many to many relationships which links to customer table while registerting through 4 JSP pages. My question is do I have implment the Entity Bean writing data to all linked Tables at once or Can I write different enetity beand to talk to individual related tables and rollback if a user makes a mistake.
First, there is no good way to "wrap" a transaction around a sequence of JSP pages. This is because and you can't really control what the user is going to do. They may just go to amazon to buy some books half way thru the third page and never come back. Also, each of these pages is a separate http request. So the only real chance you have is to do bean managed transactions in a stateful session bean and hold the handle to the bean in the users http session. Then, you have to deal with timeouts and lots of junk. It's not recommended. So one way around this is to grab all the data from the database at the beginning and save the values in the HTTP session. Modify it as the user progresses thru the 4 pages, and then when they are done, you can post it back to the database. If the user gets bored and surfs over to yahoo, you don't have any database problems - the data values will just expire when the session times out and all that you did to the database was read. This works really well and is easy to understand and maintain. When the user pushes the final "Confirm" button on the last page, you do one (transactional) commit to the database to register their changes. The only problem you might have is when you have several users trying to modify the same data. There are two normal solutions to this - one is "last one wins". This is easiest, and is often adequate. Another solution to this is to use optimistic locking. One of the columns in the database table represents a "data version number" and every time you change anything, you increment this version. So when you do the database update on page 4, you also check that the version number is the same as the one you read from the database back on page 1. If it is different, then somebody else has changed something and you have to notify your user to "start over". If you are nice, you might do some kind of "merge" for them. This is not a really great solution, but you have to realize that you are mixing two reasonably incompatible concepts (the database, which is conversational - and http which is request-driven and stateless). Something has to give.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com