Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Websphere and the fly likes Transaction Rollback  not rolling back the Database updates !! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Websphere
Bookmark "Transaction Rollback  not rolling back the Database updates !!" Watch "Transaction Rollback  not rolling back the Database updates !!" New topic
Author

Transaction Rollback not rolling back the Database updates !!

harsha av
Greenhorn

Joined: Sep 02, 2004
Posts: 17
Hi,

I am trying to update a certain number of rows in the database, using container managed transaction.

The updates are happening correctly, except when i am throwing an exception from the bean , the updates to the database are not rolled back.

Any pointers to why its happening and how to specify a TxDataSource in WebSphere v5.1 is greatly appreciated .

Regards,
Harsha
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
The container will not rollback the transaction if an application exception is thrown as it is assumed that the client expects that exception (can recover from it). As an application exception is a checked exception, check what you are throwing. Could it be SQLException? If so, you probably won't want to throw this, in which case you should wrap it in EJBException and throw EJBException.

If you do throw an application exception but decide that it makes no sense to continue with the transaction, then you must first invoke setRollbackOnly() followed by the throwing of that application exception. setRollbackOnly() will force the container to rollback the transaction.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
harsha av
Greenhorn

Joined: Sep 02, 2004
Posts: 17
The exception is a business exception, and I have to throw it as a business exception rather than throwing as EJBException. Could this be solved by marking the transaction for rollback in the catch block of the business exception in the session bean and rethrowing the same ??

Regards,
Harsha
harsha av
Greenhorn

Joined: Sep 02, 2004
Posts: 17
I will try marking the transaction for rollback as suggested by calling setRollbackOnly( ).

Thanks,
Harsha
Ken Loh
Ranch Hand

Joined: Feb 16, 2005
Posts: 190
What you would like to consider is to let your exception to subclass from a runtime exception. Then the rollback will kick in.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
What you would like to consider is to let your exception to subclass from a runtime exception. Then the rollback will kick in.

This would be correct if the bean must throw a system exception, thus forcing the container to rollback the transaction.

But harsha refers to a business exception being thrown, so it is reasonable to believe that this is an application exception which the container will always propagate to the client without a transaction rollback. But sometimes it is right to abandon a transaction even when an application exception is thrown, which is why I said that the setRollbackOnly() method must be invoked before throwing the application exception.
harsha av
Greenhorn

Joined: Sep 02, 2004
Posts: 17
right on target !!
marking the transaction for rollback did the trick !


But any particular reason why, an application exception does not qualify for a roll back implicitly? . Business exceptions are excpected by the client , but most of the cases , this sort of an exception ,might occur in the middle of a transaction , which should be rolled back. Could the container be told to roll back for all exceptions , any settings that could be done?


Thanks,
Harsha
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
I have to ask what sort of business exceptions should be rolled back "most of the cases" as business exceptions should normally be handled by the client. Are these actually system exceptions? If so, then you should be throwing system exceptions. You will usually do this by:

- ducking any RuntimeException (or subclasses thereof), thus making the container handle the exception (write a log entry, rollback, kill the bean instance, send RemoteException or EJBException to a remote or local client respectively)

- catching an exception, eg SQLException, turn it into a system exception by wrapping it in and throwing an EJBException (which causes the same actions as above as EJBException IS-A RuntimeException).

- invoking setRollbackOnly().

So, you will only get a container-managed rollback for a CMT bean if it throws a system exception or invokes setRollbackOnly().
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Transaction Rollback not rolling back the Database updates !!
 
Similar Threads
EJB transactions
Transaction rollback on another AppServer
MDBs and Transactions
MDBs and Transactions
Transaction management