I have a web application that is implemented using Spring, Hibernate, and Struts. I trying to handle rollbacks with an exception occurs and I have no idea what approach to take (...since I haven't done this before).
Here's are the steps of what it's doing:
Page 1. User chooses a business package. Page 2. User enters their business details (backend: business info. stored in database and user linked to business.) Page 3. Payment Summary is displayed and user makes a payment. (backend store payment transaction and like to user and business.)
So, if any exception occurs in Page #3, how do I rollback all the transactions in Page 1 and Page 2?
Joined: Oct 13, 2005
If they really were transactions on page 1 and page 2, I don't think you can roll them back. Maybe you should work out some way of recording the information so you can put the whole lot into a single transaction.
Originally posted by Campbell Ritchie: If they really were transactions on page 1 and page 2, I don't think you can roll them back. Maybe you should work out some way of recording the information so you can put the whole lot into a single transaction.
Oh yeah, if there were *committed" transactions on page 1 and 2, they can not be reverted by a rollback. However, you can execute a compensatory database query(if you update a database) to remove the entries added in page 1 and 2. Having said that, i have not seen applications doing that because doing partial commits during an atomic business process is never recommended. I am not sure how your application is designed, but mostly people will keep the data in memory(session in an HTTP based app) till the user submits the details finally. All db operations will then be in a single transaction and hence will atomically commit or rollback. [ January 22, 2008: Message edited by: Nitesh Kant ]
Why would you want to rollback everything when a payment error occurs? It seems to me that you have two quite separate business processes (standing data set up and payment), so you should have separate transactions for these processes. If the Payment Summary fails, your client can implement some recovery procedure, eg invite the user to make payment by another method or try again later.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Joined: Jul 18, 2006
thnx for suggestions; here are anothers to your questions:
1. The users are paying to create a business profile on the website. The different packages have different features. That's why I want to remove the business profile from the system; if the payment transaction fails. I don't want to have orphan business records laying around in the database.
2. When you say store the business profile in memory, do just mean I should store it in a session? I'm affraid that I'll run into memory leak issues if I take this approach. It's an idea...please elaborate; since I'm new to coding.
3. My approach was to store the businessId into a temp_table. Then when an exception occurred; the exception handling method will delete the record from the Business table using this businessId. Hopefully, this delete will cascade into the foreign key tables. However, I ran into a brick-wall trying to figure out how the exception handling will get this businessId in the first place. Because the exception handling should handle all exceptions.
Joined: Sep 29, 2002
When you say store the business profile in memory, do just mean I should store it in a session? I'm affraid that I'll run into memory leak issues if I take this approach.
Why would you think that you would suffer memory leaks? HttpSession objects are meant to store user input data, although they are often wrongly used to store far too much data such as search results.
You could use HttpSession objects to store user input and then submit the whole lot in one transaction.
You could always temporarily store user input data in a database, but performance is much better using in-memory objects.
On another but related subject: it is important that transactions should be as short as possible. So, never have transactions span user input, which is what you are trying to do.
Joined: Jul 18, 2006
In a given time, there could be 1000 current users creating business profiles. So, if the application is temporary storing all this information in session objects; I'm assuming this is not good practice.
I'm not too familiar with memory allocations for session storage; but in previous projects I've been on, we were always told not to store data in sessions.
Nina: we were always told not to store data in sessions.[/QB]
None of the "tips/recommendations" are universally applicable. If someone has said that one should *not* store data in sessions then it totally challenges the existance of HttpSession class itself. One thing i agree is someone should not dump useless and huge data into session. Additionally, one should clean the data from the session when it is not required anymore. 1000 concurrent users does not really make the difference if you store some data (in your case the business profile data) in the session, as long as your server is able to handle 1000 concurrent users. Additionally, you will not store data for 1000 users in one session object, one session object will have data of one user only.
So, storing data in a session that spans across multiple requests is not a bad practise but an appropriate design. It will make your application perform a lot better than storing the temp data in a DB.
Joined: Jul 18, 2006
Great...I appreciate your tips and suggestions. U R all the BeST!