Too lazy to write it myself. Forget it.
Reprinted from: http://hi.baidu.com/iduany/item/20f8f8ed24e1dec5bbf37df7
1). Spring's AOP, or declarative transaction management, defaults to rollback for unchecked exceptions. That is, by default, the RuntimeException() exception or its subclasses are rolled back; checked exceptions, that is, Exceptions that can be caught by try{} will not be rolled back, if the unchecked exception thrown by try-catch is not caught in the catch block If the transaction is explicitly rolled back by using the spring api by hard-coding the page, the transaction will not be rolled back. "Capture the exception, and do not explicitly commit the transaction in the catch block = swallow the exception alive". To catch non-runtime exceptions, the following configuration is required:
Solutions:
1. Throw RuntimeException in the class for the transaction instead of throwing Exception.
2. Add rollback-for in txAdive and write your own exception in it, such as your own exception:
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name= "*" rollback-for="com.cn.untils.exception.XyzException"/>
</tx:attributes>
</tx:advice>
Or
define an exception that will not roll
<tx:advice id="txAdvice">
< tx:attributes>
<tx:method name="update*" no-rollback-for="IOException"/>
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
2) .
Generally, there is no need to catch exceptions in business methods. If you have to catch, you must throw a runtime exception after you have done the work you want to do (such as closing files, etc.), otherwise spring will commit your operation, which will generate Dirty data. So your catch code is superfluous.
Such as:
try {
//bisiness logic code
} catch(Exception e) {
//handle the exception
}
It can be inferred from this that if a business method is wrapped in a whole in spring, the business method is equivalent to being separated from the management of spring transactions, because no exception will be thrown from the business method! All are caught and swallowed, causing the spring exception to trigger the transaction rollback strategy to fail.
However, if you use the spring api to explicitly roll back the transaction by hard-coding the page in the catch code block, it is not impossible to write this way.
3). Things based on annotations:
Transactional exception control, the default is Check Exception not rollback, unCheck Exception rollback
If rollbackFor and noRollbackFor are configured and both use the same exception, then the exception is encountered, or rollback
The configuration of rollbackFor and noRollbackFor may not cover all exceptions. For missing ones, check Exception will not be rolled back, and unCheck Exception will be rolled back.