Throws exception does not roll back when it comes to spring declarative transactions

Excerpted from http://cn-done.iteye.com/blog/775519

Some time ago, Project code review, found that TX does not use spring transactions, and the direct encapsulation method, manual data Rollback, learned that the reason is: after throwing an exception, the transaction does not work, no rollback. This reason suddenly makes people very silent, but also a clever TX, know the alternative, but in the INSERT, manual rollback of the direct delete can be, if it is update, do not know what will be more sharp way.

Carefully review the code details and found that the TX did not follow the framework originally designed in the service layer throws businessexception, but directly throws Exception. Spring Configuration Exception rollback takes the Rollback-for= "Businessexception". TX Raises the question: is spring not throwing an exception transaction and will it be rolled back? With questions, consult the data, analyze the source code, and finally find the answer you want. It all comes from the difference between a Java check exception and a non-check exception.

Using spring will inevitably use spring's transaction management, and it is natural to use transaction management to choose Declarative transaction management, in the spring documentation, spring declarative transaction management defaults to non-checked exceptions and runtime exceptions for transaction rollback, A rollback operation is not performed on a check-type exception.
So what is a check-type exception and what is a non-check exception?
The simplest point of judgment is two:
1. A non-check exception that inherits from RuntimeException or error, and inherited from exception is a check-type exception (of course, runtimeexception itself is also a subclass of exception).
2. The non-check type exception can not be captured, and the check type exception must be handled with a try statement block or the exception to the superior method processing, in short, must write code to deal with it. So you have to catch the exception at the service and then throw it again, so the transaction just works.

Throws exception does not roll back when it comes to spring declarative transactions