File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JDBC and the fly likes How to handle transaction Rollback on Exception Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "How to handle transaction Rollback on Exception" Watch "How to handle transaction Rollback on Exception" New topic
Author

How to handle transaction Rollback on Exception

Nina Anderson
Ranch Hand

Joined: Jul 18, 2006
Posts: 148
Hi,

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?

Pls....HeLP.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40027
    
  28
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.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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 ]

apigee, a better way to API!
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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
Nina Anderson
Ranch Hand

Joined: Jul 18, 2006
Posts: 148
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.

PLS...advice...
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
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.
Nina Anderson
Ranch Hand

Joined: Jul 18, 2006
Posts: 148
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.
Nitesh Kant
Bartender

Joined: Feb 25, 2007
Posts: 1638

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.
Nina Anderson
Ranch Hand

Joined: Jul 18, 2006
Posts: 148
Great...I appreciate your tips and suggestions. U R all the BeST!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to handle transaction Rollback on Exception