Spring-Java Things Rollback Failure Processing Recently, I was working on a project and accidentally found that a class was throwing things rollback operation, and the data was inserted into the database normally, so I carefully checked and looked at the specific reason.
Everything still starts with Java's checked exceptions and non-checked exceptions.
So what is an inspection type exception and what is a non-inspection type exception?
There are two simplest judgment points:
1. The non-checking exception inherited from RuntimeException or Error, while the checking exception inherited from Exception (of course, RuntimeException itself is also a subclass of Exception).
2. Non-checked exceptions can be caught without being caught, while checked exceptions must be processed with try... catch statement block or handed over the exception to the superior method for processing. In short, code must be written to process it.
The exception structure of Java is shown in the figure below. Among them, exceptions that directly inherit Exception must be caught and are checked exceptions.
Let's look back at my code:
1. The method name is preceded by
@Transactional
2. Spring configuration file applicationContext-XXX.xml also has related configurations for Spring things.
<bean id="transactionManager" > <property name="dataSource" ref="dataSource" /> <property name="rollbackOnCommitFailure" value="true"></property> </bean>
But why does the thing that has been submitted after the try... catch throwing Exception exception is not rolled back when the Service layer method is called?
After checking the relevant spring documentation, I found that the original spring declarative transaction management performed transaction rollbacks on non-checked exceptions and runtime exceptions by default, while no rollbacks on checked exceptions.
The Exception thrown by try... catch in the code is a check type exception. Spring's framework will not roll back by default.
In programming, non-checked exceptions can be avoided, while checked exceptions must be processed with try statement blocks or handed over to the superior method to handle them. In short, code must be written to process them.
Therefore, the exception must be caught in the service and then manually throw a non-checked exception again so that the transaction can take effect. For example:
try{ ……… } catch (Exception e) { ……… throw new BusinessException(e.getMessage()); }Of course, we have an easier way to solve this problem, that is, change the default rollback method by annotating parameters.
NoRollbackFor and RollbackFor are defined in the @Transaction annotation to specify whether a certain exception is rolled back.
Use examples:
@Transaction(noRollbackFor=RuntimeException.class)
@Transaction(RollbackFor=Exception.class)
Therefore, in the above question, you can directly add the rollback parameter @Transaction (RollbackFor=Exception.class), which changes the default transaction processing method.
Revelation:
This requires us to inherit the custom exception from RuntimeException when customizing the exception, so that when thrown, it will be handled accurately by Spring's default transaction processing.
Summarize
The above is the entire content of this article about the problem of failure of Java transaction rollback. I hope it will be helpful to everyone. Interested friends can continue to refer to other related topics on this site. If there are any shortcomings, please leave a message to point it out. Thank you friends for your support for this site!