Shulou(Shulou.com)06/02 Report--

How to solve the problems caused by the wrong use of SpringBoot, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

One day, a business line with shoes came to the author and said that one of their application transactions failed without rollback. You have already checked the data with DBA, and you have no problem seeing how transactions are used in your code. Later, in the author's repeated work, the cause of the problem was found. The cause of the failure is simple, but the new path of the query is worth talking about.

If the business children's shoes are right. Transaction configuration is successful and valid. Then the question behaves strangely, or almost impossible. So the first object of my suspicion is:

1. Transaction configuration error

Through simple tracking and testing, there is really no problem in finalizing the transaction. There are 10,000 question marks in my mind at this time.

two。 In the follow-up, all the colleagues around them were interested in the problem and put forward hypotheses one by one, which were eventually excluded.

In desperation, the author has to track the code a little bit, although the debug mode of Idea is already very easy to use, but it is still a little difficult to operate.

Fortunately, Huang Tian lived up to the painstaking efforts, and there was a flash of inspiration, and he guessed whether it would be the data source for execution and there was no transaction. The data source created is not the same as when the application starts.

With a try attitude, I put the breakpoint in the location where the data source bean was generated at startup. In the end, it was found that the startup generated bean was not the same as the running bean. Shame!

Here are the reasons:

According to the business code, the conditions under which the problem occurs

During startup, the startup exception is eaten, so that the container cannot be terminated because of the exception.

During startup, an exception is thrown

Cause analysis

After the spring container starts, initialize bean: DataSource (A)

Mybatis cache DataSource (A)

Container startup exception, spring clears all cached bean information.

Due to the startup class, the container startup exception was eaten. The container didn't hang up.

At this point, after the dubbo request comes in, all the bean information in the spring is cleared. The container reinitializes the bean. DataSource (B) and transaction manager are generated at this time

Before the transaction method executes, the transaction manager sets setAutoCommit=0 to DataSource (B). And store the relationship between DataSource and transaction in map (C).

Myabtis gets the transaction information according to DataSource (A) from the map in step 6 when executing. In this case, it is not available. It is DataSource (A) that causes the execution of the sql execution. And this DataSource (A) never sets setAutoCommit=0. Causes the transaction to not be rolled back

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.