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

This article mainly introduces "how to understand Spring two-tier transactions". In daily operation, I believe many people have doubts about how to understand Spring two-tier transactions. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand Spring two-tier transactions". Next, please follow the editor to study!

Spring two-tier transaction, where is the exception I threw?

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] ");} @ SpringBootTestpublic class NoteTests {@ Resource private NoteService noteService; @ Testpublic void saveNote () {NoteEntity entity = new NoteEntity (); entity.setTitle (" Nian Nujiao Chibi nostalgia "); entity.setContent (" the river goes east, the waves are swept away, the romantic figures are immortal. " 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 I want to get synchronization anomalies here! [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 ());} for a reason

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 currently has no transaction, then create a transaction; if there is a transaction, join the transaction, which is the most commonly used setting. 2. If there is a transaction in PROPAGATION_SUPPORTS, join the transaction, and if there is no transaction, it will be executed in a non-transactional manner. 3. If there is a transaction in PROPAGATION_MANDATORY, join the transaction; if there is no transaction, an exception is thrown. 4. PROPAGATION_REQUIRES_NEW creates a new transaction unconditionally. 5. PROPAGATION_NOT_SUPPORTED is executed in a non-transactional manner, suspending the current transaction if there is a current transaction. 6. PROPAGATION_NEVER runs in a non-transactional manner. If there is a transaction, an exception is thrown. 7. Before PROPAGATION_NESTED starts to execute a transaction, save a savepoint. When an exception occurs, roll back to the savepoint; when there is no exception, commit or roll back along 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?

Naturally, there is no silver bullet, so 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.

At this point, the study on "how to understand Spring two-tier affairs" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.