Spring's @Transactional does not rollback on checked exceptions
Self-employed advisor for a holistic view on the whole software engineering process. Developing people, developing organizations, developing software. Still passionate coder.
Search for a command to run...
Self-employed advisor for a holistic view on the whole software engineering process. Developing people, developing organizations, developing software. Still passionate coder.
No comments yet. Be the first to comment.
TL;DR This post explains how iOS Universal Links work and what is required to implement them. It covers how to handle incoming links in an iOS app, how to create and configure the Apple App Site Association (AASA) file, and how to correctly host the ...

TL;DR The Page Object Model (POM) is the industry standard, but it is not easily scalable. The Flow Model Pattern improves upon the basic POM, offering a perfectly balanced solution that is not overly complex yet still scalable. The Screenplay Patter...

Preface In a previous article from the start of this year, I mentioned various frameworks that can be used for mobile test automation. The one that came up repeatedly was WebdriverIO, which I have been using actively for over two years now. It is a s...

Let’s be honest - who wakes up and and is excited to read button labels or error messages? But have you ever clicked a vague “Next” button and immediately regretted it because you had no idea where it was taking you? Or stared at an error message lik...

Part 1 - An Introduction to the matter What will this series be about? During this series of blog posts, I will do my best to provide my opinion on specific models, determine which use case each one fits, discuss the pros and cons of using that model...

We’re using the Spring Framework in most of our applications (and thus also in the Cloudflight Platform) and are really satisfied with it.
One of the big advantages is the the declarative transaction handling using the @Transactional attribute.
import org.springframework.transaction.Transactional;
@Transactional
public class MyService implements IMyService {
public List getResults () {
// do something
}
public void foo() {
throw new java.lang.UnsupportedOperationException();
}
public void bar() {
throw new java.lang.Exception();
}
}
That simple annoation on class managed by a Spring ApplicationContext causes all method calls onto that service to be bound to a transaction. The transaction is committed after the method call has left the service again and it’s rollbacked for the case an exception is thrown (e.g. after calling the (quite silly) method foo()).
But be careful: Only unchecked exceptions (that is, subclasses of java.lang.RuntimeException) are rollbacked by default. For the case, a checked exception is thrown, the transaction will be committed!
The Spring documentation explains that as follows:
While the EJB default behavior is for the EJB container to automatically roll back the transaction on a system exception (usually a runtime exception), EJB CMT does not roll back the transaction automatically on an application exception (that is, a checked exception other than java.rmi.RemoteException). While the Spring default behavior for declarative transaction management follows EJB convention (roll back is automatic only on unchecked exceptions), it is often useful to customize this.
And that customization can be done very easily by just adding the parameter rollBackFor to the @Transactional attribute:
import org.springframework.transaction.Transactional;
@Transactional(rollbackFor = Exception.class)
public class MyService implements IMyService {
public List getResults () {
// do something
}
public void foo() {
throw new java.lang.UnsupportedOperationException();
}
public void bar() {
throw new java.lang.Exception();
}
}
In that case, the transaction will even be be rollbacked on a call to the method bar().