Spring transaction management only rolls back when a run-time exception occurs

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.

Conclusion:

In the spring transaction management environment, using unckecked exception can greatly simplify the handling of exceptions by declaring the possible exceptions at the transaction level (the exception here can be a custom unckecked exception system). In all the middle tier just need simple throws can, do not need to capture and processing, directly to the top layer, such as the UI layer and then the exception of the capture and processing

With @transactional in front of the service class, declare that all methods of the service require transaction management. Each business method starts with a transaction open.

Spring defaults to a transaction rollback of the run-time exception (RuntimeException). The exception is unchecked.

If you encounter a checked accident, do not roll back.

How to change the default rule:

1 Let checked exception also rollback: Add @Transactional before the whole method (Rollbackfor=exception.class)

2 Let unchecked exception not rollback: @Transactional (Notrollbackfor=runtimeexception.class)

3 (Query-only) methods that do not require transaction management: @Transactional (propagation=propagation.not_supported)

Note: If the exception is try{}catch{}, the transaction is not rolled back, and if you want the transaction to roll back, you must throw the Try{}catch{throw Exception} out.

A unified exception hierarchy is required to provide a service abstraction. The most important thing is org.springframework.dao.DataAccessException and its subclasses. It is important to emphasize that spring's anomaly mechanism focuses on the application programming model. Unlike SqlException and other data access APIs, spring's exception mechanism is to allow developers to use the least, clearest code. DataAccessException and other underlying exceptions are non-check exceptions (unchecked exception). One of the principles of spring is that grassroots anomalies should be non-censorship exceptions. The reasons are as follows:
1. Grass-roots anomalies are generally not recoverable.
2. An inspection exception will reduce the value of the exception hierarchy. If the underlying exception is checked, then you need to add a catch statement to capture it everywhere.
3.try/catch code blocks are lengthy and confusing, and do not add much value.
Using check exceptions is good in theory, but it does not seem to be the case.
Hibernate3 will also switch from an inspection exception to a non-check exception.

Spring transaction Management only rolls back a run-time exception