There are a lot of articles on the Internet about Spring transaction propagation and isolation, and there are irresponsible direct copying of the meaning of the noun. Although many of the articles are in the cloud, we will give examples to study with you today.

Spring gives frequently interviewed questions about the implications of four features of Spring transactions – this is easy to understand

2. Definition and case analysis of Spring transaction propagation feature

ACID

I can’t remember the spelling of these four English words

  • Atomicity: A transaction is a series of atomic operations that either all succeed or all fail.

  • Consistency: Once complete (whether successful or unsuccessful), ensure that it is in a consistent series of business states, all of which are successful or all of which are failed, not part of the success and part of the failure.

  • Isolation: When different transactions process the same data for a business at the same time, the transactions need to be independent of each other and the data between them is not affected.

  • Durability: Once a transaction completes, data after the transaction is persisted and does not change due to restarts or other operations, regardless of systemic errors.

Second, the definition of Spring transaction propagation feature and case analysis

Let’s start with the definitions and then do a simple code analysis

If you want to use transactional Spring XML in your project, you must enable transactions. The following features are generally configured in XML properties.

<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
Copy the code

This is a DB transaction with JTA and JPA as well as Herbernate, etc., here I will not expand the description, can be found by myself.

7 behaviors of transaction propagation

1. There is no transaction. In this case, the first insert with ID 16 succeeds and the second insert fails, and the data of the first time is retained in the database

Transaction-free running

2, propagation_REQUIRED, the default transaction propagation behavior required, delete data 16 in the table during Experiment 2 to avoid affecting the following test. Transactional Transactional(Propagation =Propagation.REQUIRED) == @transactional Transactional(Propagation =Propagation.REQUIRED)

The propagation behavior of the transaction is required because a primary key conflict rolled back the transaction, so neither data was inserted.

3, Execute a transaction, propagation_SUPPORTS, if there is no transaction, execute a non-transaction

Transaction propagation behavior is supports because the caller is not using a transaction and is running in a non-transaction, so the first data of first is inserted.

Mandatory Is a mandatory word. Mandatory is used instead of mandatory because MANDATORY cannot automatically create a transaction, propagation_MANDATORY

The propagation behavior of the transaction is manatory because there is no transaction in the outer layer of the call, two pieces of data are not inserted. Think about what happens when you write it this wayThe propagation behavior of the transaction is mandatory

5, propagation_ REQUIRED _new, another transaction is raised, regardless of whether the transaction exists, and if it exists, suspend the current transaction and re-execute the new transaction

The propagation behavior required_new of a transaction results in the same result as require: neither data is in the database, and the first data is rolled back due to a unique conflict.

Scenario 1 Does a new transaction throw exception cause the peripheral transaction to roll back?

Scenario 2 Will the failure of the peripheral transaction cause a rollback of the committed new transaction?

6, propagation_ not _support, meaning it is not running in a transaction, and suspends the transaction if it currently exists

Transaction propagation behavior not_suppoted under this situation, if you are in my thoughts move should be able to think of id for the incoming of 17, the second primary key conflict while however notSupportSonTransationsl () this method have no transaction so does not affect the first library, However, the peripheral transaction with ID 16 will be rolled back, so there is only one data with ID 17 in the library.

7, propagation_never, which means the current method cannot run in a transaction, —->Existing transaction found for transaction marked with propagation ‘never’

The propagation behavior of a transaction is NEVER

8, Propagation_nested, a transaction can be committed or rolled back independently of the external transaction, propagation_nested, and none of the same data falls into the database.

Nested propagation behavior of transactions

The propagation behavior level of a transaction is simply demonstrated

Authors: Creditease Institute of Technology, Wang Qiaomin