Every time you talk about Spring transactions, it seems familiar and unfamiliar. This article through an interview question and some practice, to dismantle a few Spring transaction common pitfalls.
principle
The principle of Spring transaction is: through the AOP faceted way to achieve , that is, through the proxy model to achieve transaction enhancement .
The specific process is: for the file containing the@TransactionalThe annotated methods are intercepted and then rewritten to re-insert the exception rollback logic in the methods. Moreover, each thread manages its own transactions independently and is isolated from each other.
The principle is simple and easy to use, which means that the method is typed on the@Transactionalannotation, and then the transaction takes effect normally. It's also rare that anyone verifies that a rollback is actually possible in the case of an exception.
What makes Spring Transaction familiar to me is that it looks simple everywhere, what makes it unfamiliar to me is that there are more variants when using it, and sometimes it inexplicably doesn't work.
source code (computing)
The relevant source code for the above principle is as follows:
Practice makes perfect.
But [Half a Cigarette] occasionally finds some scenarios where transactions fail during coding, there are always situations you don't expect, and there are always pitfalls waiting to be jumped into.
[half-cigarette] Think the best way to validate matters is:Remember the basics + hands-on.. Remembering the basic principles allows you to quickly deal with routine problems, and hands-on practice allows you to validate off-the-wall problems or uncertainty.
Several uses of transaction inactivity
The following are a few common uses of Spring transactions do not take effect, readers who have time must keep in mind that it is very helpful for daily coding, as well as interviews can also say a few words.
- private method
Spring implements transaction enhancement by means of AOP proxies, but private methods can't be proxied, so typing the@TransactionalThe annotation is not valid.
- Final, static modified methods
Similar to private methods, final and static modified methods cannot be proxied, so the@TransactionalThe annotations also do not take effect.
Because, static is a class method, final modified methods cannot be overridden and naturally cannot be implanted with transaction enhancement code.
- Bean objects are not managed by Spring
A class must be hosted by Spring for that to pass the@Transactionalannotation to enhance transactions. If only the@Transactionalannotation without handing the class over to Spring for hosting, the transaction is also not valid. It is similar to the following scenario:
// Not here@Serviceexplanatory note，This category is not covered byspringtrusteeship，timely@TransactionalIt doesn't work.
public class UserService {
@Autowired
private UserMapper userMapper;
@Transactional
public final void createAndUpdateUser() {
createUser();
updateUserById();
}
public void createUser() {
User user = new User();
(2L);
("test2");
("test2" + "@");
(user);
("create user");
}
public void updateUserById() {
User user = (1L);
("admin1");
(user);
int i = 1 / 0; // An exception is thrown here
("update user");
}
}
- The anomaly is swallowed
If, in the business code, an exception is caught by try..... .catch catches the exception, and at the same time does not continue to throw the exception, the Spring transaction is also not in effect.
This is because the logic of proxy enhancement is to roll back the transaction only if an exception is found. If the exception is swallowed by the method itself, the proxy assumes that there is no exception and thus cannot roll back.
- Non-RuntimeException
Spring transactions are rolled back by defaultRuntimeException and its subclasses, andError type of exception. If it is a remaining exception, it will not be rolled back. Visible at the source code:
This non-RuntimeException exception scenario requires 2 actions to be done so as to ensure transaction rollback.
- Catch the exception and then throw the custom exception.
- self-operated
@Transactionalannotation to add the@Transactional(rollbackFor = )attribute. Or just use therollbackFor =, and the first step is dispensed with.
- Scenarios for asynchronous threads
The scenario with multiple threads is just a matter of keeping in mind that each thread manages only its own transactions. Each thread has a separate transaction context that exists in ThreadLocal, so transaction information is isolated across threads.
- Hardest hit: calling methods of this class in the same class
This failure scenario is the most error-prone, and there are many variants.Calling methods of this class in the same classWhen doing so, keep the following 2 points in mind to break the ice:
- Whether or not transactions will be turned on depends on the first externally invoked method of this class. If the first externally invoked method of this class has a
@Transactionalannotation, that transaction takes effect. - Calls to your own internal methods are made using the
()approach, which doesn't go the AOP proxy way, so the called internal method's@TransactionalThe annotation does not take effect.
If you do need to call an internal method and want the transaction to take effect, then you can only separate the called internal method into a new class and hand it over to Spring to manage at the same time.
An interview question
All of the above uses of transaction inactivity are relatively easy to remember, with the exception of theCalling methods of this class in the same classThere are multiple variants of the scenario. See this interview question for more details. Ask the followingcreateAndUpdateUsermethod's transactions take effect?
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
@Transactional
public final void createAndUpdateUser() { //Notice there'sfinalqualify or modify (grammar)
createUser();
updateUserById();
}
@Transactional
public void createUser() {
User user = new User();
(2L);
("test2");
("test2" + "@");
(user);
("create user");
}
@Transactional(rollbackFor = )
public void updateUserById() {
User user = (1L);
("admin1");
(user);
int i = 1 / 0; // An exception is thrown here
("update user");
}
}
If, in accordance withHardest hit: calling methods of this class in the same classIf the 2 principles mentioned in the report are not met, then all matters are in effect.
If, in accordance withFinal, static modified methodsIf the principle mentioned in the report of the Committee on the Elimination of Racial Discrimination is not followed, the transaction will not be effective at all.
And what is the result? The result is that all the transactions of the above methods take effect.
Why? Here's a principle to add: final-modified methods with @Transactional annotations are transactional according to the transaction hosting status of the called method itself.
Because the above code in thecreateUsermethodology andupdateUserByIdmethods, all of which have@Transactionalannotation, so it all takes effect.
This particular case is also really jaw-dropping, but just keep in mind the above uses that don't work, and who has nothing better to do than to write such a@Transactional + finalWhat about the code? In addition to the interview will ask ......
summarize
This post mainly talks about several kinds of transactions do not take effect the user, interested readers can remember. Also, there is a special scenario interview question for readers to practice on their own. I hope it will be helpful to you!
The end of this article! Welcome to pay attention to, add V (ylxiao) exchange, the whole network can be searched (programmers half a cigarette)
Link to original article:/s/V5KpVk0kDhc9vWctOy7X9A
