Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about what to do if we encounter Spring double-tier transactions and do not roll back. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Recently, some fans asked me in moments how to crack the problem that I will not roll when I encounter Spring in the interview. The following is combined with a simple case, hoping to solve some people's doubts.

System A calls system B to perform data synchronization, and system B returns an error prompt. System A needs to roll back the previously saved data and throw the error message up.

The approximate code is @ Service ("noteService")

Public class NoteServiceImpl implements NoteService {

@ Resource

Private SearchService searchService

@ Transactional (rollbackFor = Throwable.class)

@ Override

Public CommonResponse save (NoteEntity note) {

/ / A series of DB operations

Try {

SearchService.sync (note)

} catch (Exception e) {

E.printStackTrace ()

}

Return CommonResponse.success (entity)

}

}

@ Service ("searchService")

Public class SearchServiceImpl implements SearchService {

@ Transactional (rollbackFor = Throwable.class)

@ Override

Public void sync (NoteEntity note) {

/ / A series of DB operations

Throw new RuntimeException ("synchronization exception! [XXX]")

}

}

@ SpringBootTest

Public class NoteTests {

@ Resource

Private NoteService noteService

@ Test

Public void saveNote () {

NoteEntity entity = new NoteEntity ()

Entity.setTitle ("Nu Jiao Chibi nostalgia")

Entity.setContent ("the great river goes east, the waves sweep away, and the romantic figures go through the ages. Therefore, to the west of the base, humanity is: the three Kingdoms Zhou Lang Chibi.")

Entity.setTags (Su Shi, Song Dynasty)

Entity.setCategory (Su Shi's Poems)

Try {

NoteService.save (entity)

} catch (Exception e) {

E.printStackTrace ()

/ / FIXME what I want to get here is a synchronization exception! [XXX]

/ / FIXME, but what you get here is Transaction silently rolled back because it has been marked as rollback-only

System.out.println (">" + e.getMessage ())

}

}

}

Where there is smoke, there is fire

The code has a long history, and why it is written in this way can no longer be traced.

After wondering for a while, when I saw the two-tier transaction, I thought of the Spring transaction propagation mechanism, which was understood more shallowly.

Without special configuration, we naturally follow the default transaction propagation mechanism, that is, Propagation.REQUIRED.

International practice, listing transaction communication mechanisms:

1 、 PROPAGATION_REQUIRED

If there is no transaction, a transaction is created; if there is a transaction, the transaction is joined, which is the most commonly used setting.

2 、 PROPAGATION_SUPPORTS

If there is a transaction, join the transaction, and if there is no transaction, it will be executed in a non-transactional manner.

3 、 PROPAGATION_MANDATORY

Join a transaction if there is a transaction, or throw an exception if there is no transaction.

4 、 PROPAGATION_REQUIRES_NEW

Create a new transaction unconditionally.

5 、 PROPAGATION_NOT_SUPPORTED

Execute in a non-transactional manner, suspending the current transaction if there is a current transaction.

6 、 PROPAGATION_NEVER

Run in a non-transactional manner, throwing an exception if there is a transaction.

7 、 PROPAGATION_NESTED

Save a savepoint before starting the transaction, and when an exception occurs, roll back to the savepoint; when there is no exception, commit or roll back with the external transaction.

Specific reasons

1. After looking at the transaction propagation mechanism above, we continue to refine the problem. The inner and outer layers share a transaction, and the inner layer throws an exception, which will cause the whole transaction to fail.

2. Continue the analysis. If the outer layer logic try catch, the inner layer exception cannot be thrown upward, and the outer layer transaction will continue to commit.

3. When the transaction commits, the transaction status is judged, and it is found that the transaction is failed and needs to be rolled back, so an exception of Transaction silently rolled back because it has been marked as rollback-only is thrown.

How to solve it?

Choose the right solution according to the business scenario.

1. In the current scenario, you can simply remove the try catch from the outer logic. If the exception is thrown directly up, the transaction will not continue to commit, and the caller will get the first-hand exception.

2. If the inner layer is not the core logic and record a log or something, you can configure the inner transaction to @ Transactional (rollbackFor = Throwable.class, propagation = Propagation.REQUIRES_NEW). In any case, a new transaction is created, and the outer transaction is not affected by the inner transaction. However, there is a problem. The outer transaction fails, but the inner transaction still stores the records, which may produce dirty data.

3. If the outer transaction fails and the inner transaction cannot be committed, you can use @ Transactional (rollbackFor = Throwable.class, propagation = Propagation.NESTED). Note: hibernate/jpa does not support nested transaction NESTED, it can be replaced by JdbcTemplate.

Finally, the following fan summed up the issue of ineffectiveness, we keep in mind. If you can say it all in the interview, Offer is basically stable.

After reading the above, do you have any further understanding of what to do if you encounter Spring double-tier transactions without rollback? If you want to know more knowledge or related content, 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.