I'm looking for generic code pattern to properly handle transaction with respect to possible exception. I assume there is common code pattern for that, no matter what concrete kind of transaction we are dealing with.
I have a method that executes something in transaction and want to rethrow Exception that may occur when inside transactional code block. Here is an example of such method:
protected void doIt() {
// for JDBC connection transaction may be started automatically
// but assume we start it here
Tran tran = session.beginTran();
try {
// here comes code that does some processing
// modifies some data in transaction
// etc.
// success - so commit
tran.commit();
} catch (Exception ex) { // many different exceptions may be thrown
// subclass of RuntimeException, SQLException etc.
// error - so rollback
tran.rollback();
// now rethrow ex
throw ex; // this line causes trouble, see description below
}
}
Now - there is compile error in method doIt
. It must declare throws Exception
but this is not acceptable because method doIt
is used in many places and adding throws Exception
leads to subsequent modifications in places of direct and indirect use of doIt
. It's because of known Java Language design problem with declared exceptions.
Now the question: how to change exception vs transaction handling code to achieve my goal - properly handle transaction finalization (perform commit or rollback based on success condition) and rethrow exactly the same exception that may be catched in transactional code block.
I know that I could do something like throw new RuntimeException(ex)
but this throws exception of other class and I want to avoid such solution.
So if you throw an Exception or a subclass of it, always use the above with the @Transactional annotation to tell Spring to roll back transactions if a checked exception occurs.
If a commit succeeds then its done, complete, you can't roll it back at that point. You have to mark a transaction for rollback before calling the commit method.
I'd go for something like this.
protected void doIt() {
// for JDBC connection transaction may be started automatically
// but assume we start it here
Tran tran = session.beginTran();
bool success = false;
try {
// here comes code that does some processing
// modifies some data in transaction
// etc.
// success - so commit
tran.commit();
success = true;
} finally {
// error - so rollback
if (! success)
tran.rollback();
}
}
.. or if tran has a method where you can query the status (tran.isFinished()) or something, you don't need the bool. Any thrown exception (i.e. runtimeexception or error, if there are no checked exceptions) will just fly on by, executing the finally block on it's way up the stack.
If rollback throws exceptions, you'll need to catch those and log-em or something (a failed rollback is a very serious condition). Remember NOT to throw anything in that case, as the exception which is currently unwinding the stack will be lost.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With