"Transaction properties for spring transactions"

As you all know, spring's declarative transactions are defined by transaction properties, and spring's transaction properties contain 5 aspects: propagation behavior, isolation level, read-only, transaction timeout, rollback rule;

Propagation behavior

Propagation behavior, which is a property that is related to a transaction boundary, defines when to create a transaction or when to use an existing transaction.

Spring provides 7 different types of propagation behavior:

Propagation_required the method must run in a transaction, and if the current transaction does not exist, a new transaction is initiated, and if the current transaction exists, it is most common to execute in this transaction; Propagation_mandatory the method must be done in a transaction, Throws an exception if there is no transaction, propagation_nested if a transaction is currently present, the method will run within the nested transaction, and the nested transaction can be individually committed or rolled back independently of the current transaction. If there is no current transaction, the same operation as Propagation_required is performed; Propagation_supports indicates that the method does not need to be run in a transaction, if a transaction is currently present, runs in that transaction, and if it does not, runs as non-transactional The propagation_requires_new means that the method must be running in its own transaction. If a transaction is currently present, the transaction is suspended, a new transaction is started to execute the method, propagation_not_supported indicates that the method should not run in the transaction, and if the transaction is currently present, the transaction is suspended during the method run; propagation _never indicates that the method should not run in a transaction and throws an exception if a transaction is currently present;

If the propagation behavior of a method is declared as propagation_requires_new, this means that the transaction boundary is the same as the method's own boundary: The method starts a new transaction at the start of execution and ends the transaction when the method returns or throws an exception.

Isolation level

The isolation level determines the degree to which a transaction can be affected by other parallel transactions

1. Why is there a transaction isolation level and a problem that can be resolved (why)?

In a multi-user system, the concept of transaction isolation mechanism is introduced in order to ensure the consistency and integrality of data, avoid dirty reading, non-repetition reading and phantom reading, etc.

2. Dirty reading, non-repeatable reading, phantom reading concept?

Dirty reads: One transaction reads to another transaction uncommitted update new data. When a transaction is accessing the data and the data has been modified, and the modification has not yet been committed to the database, another transaction accesses the data and then uses that data. Because this data is not yet committed data, then another transaction read the data is dirty data, according to the dirty data can also be incorrect operation;

Non-repeatable READ: In the same transaction, multiple reads of the same data return different results. In other words, a subsequent read can read the updated data that was committed by another transaction. Conversely, "repeatable read" can guarantee the same read data when it is read more than once in the same transaction, that is, subsequent reads cannot be read to the updated data submitted by another transaction.

Phantom reads: Similar to non-repeatable reads, but the difference is that non-repeatable reads are update, and the Phantom reads insert. The transaction T1 executes a query, and then the transaction T2 a new row of records, which exactly satisfies the conditions of the query that T1 uses. Then T1 again uses the same query to retrieve the table again, but at this point you see the new row that the transaction T2 just inserted. This new line is called "Phantom", because for T1 this line is like a sudden appearance.

3. Transaction ISOLATION level?

In general, it is divided into four isolation levels:

A. Unread READ UNCOMMITTED: READ UNCOMMITTED data, which is the lowest level of isolation in a transaction, in a concurrent transaction, which allows one transaction to read the uncommitted update data of another transaction (dirty reads, non-repeatable reads, and Phantom reads);

B. Read committed: Read committed data, to ensure that in a concurrent transaction, a transaction modified data submitted before being read by another transaction (will appear non-repeatable read and Phantom Read);

c. REPEATABLE READ (REPEATABLE READ): Repeatable read, this level of transaction isolation prevents dirty reads and cannot be read repeatedly. However, Phantom reads may occur. In general, the use of "snapshot" approach to achieve;

D. Serializable (Serializable): Transactions are processed for sequential execution, or in serialized form. This is the highest-cost, but also the most reliable, transaction isolation level. can effectively avoid dirty reading, non-repeatable reading, Phantom reading.

4. What is the default isolation level for the database?

　　The default isolation level for each type of database is different, such as SQL Server, Oracle default read commited,mysql default repeatable read.

Reference from: https://gist.github.com/JagoWang/4555317#file-mysql-L27

Https://tech.meituan.com/innodb-lock.html

is read-only

If a transaction only reads from the back-end database, the database can take advantage of the read-only feature of the transaction to perform some optimizations, and by setting the transaction to read-only, you can give the database an opportunity to apply the optimizations it deems to be, such as Oracle for read-only transactions, no rollback segments, and no log rollback log;

If you execute more than one query statement at a time, such as a statistical query, a report query, in this scenario, multiple query SQL must guarantee the overall read consistency, otherwise, after the first SQL query, the second SQL query, the data is changed by other users, Then the overall statistical query will have a state of inconsistent read data, and transaction support should be enabled at this time.
"Note that it is time to execute multiple queries to count certain information, in order to ensure consistency in the overall data, read-only Transaction"

When there is no transaction, a SQL statement is executed to see the data state of the pre-execution point to ensure data consistency;

Read-only transactions, the execution of multiple SQL statements to see the data state of the pre-execution point, to ensure data consistency;

Transaction timeout

In order for the application to run better, the transaction cannot run for a long time. Because transactions can involve locking back-end databases, long-time transactions unnecessarily consume database resources.

Rolling back rules

By default, transactions are rolled back (Java.lang.RuntimeException and their subclasses) only when they encounter a run-time exception, and are not rolled back when they encounter a check-type exception, but we can manually set the type of the exception when the rollback occurs;

We can use the norollbackfor and rollbackfor in the @transaction annotation to specify whether an exception is rolled back.

@Transaction (Norollbackfor=runtimeexception.class) @Transaction (rollbackfor=exception.class) This changes the default transaction mode.

This requires that the custom exception be inherited from the runtimeexception when the custom exception is thrown, so that it will be handled accurately by the spring default transaction.

Reference from "Spring Combat"

Transaction properties for spring transaction