How to understand spring transactions and the use of declarative transactions

The content of this article is about how to understand spring transactions and the use of declarative transactions, including the isolation level of things in the database. It has certain reference value. Friends in need can refer to it. I hope it will be useful to you. Helps.

The use of spring transactions and declarative transactions

(Students, start reviewing the database knowledge given to teachers by the university!!)

Transaction: A program execution unit (unit) that accesses and possibly updates various data items in the database.

Transactions have four attributes: (ACID)

Atomicity: A transaction is an indivisible unit of work, and all operations included in the transaction are either done or none.

Consistency; the transaction must change the database from one consistency state to another consistency state. Consistency and atomicity are closely related.

Isolation: The execution of a transaction cannot be interfered with by other things. That is, the internal operations and data used in a transaction are isolated from other concurrent transactions, and transactions executed concurrently cannot interfere with each other.

Persistence: Persistence, also called permanence, means that once a transaction is submitted, its changes to the data in the database should be permanent.

Transaction purpose: To maintain data consistency and integrity.

Consistency: The data status of a business chain is consistent and cannot be partially changed and partially unchanged.

Integrity: The data of a business chain is complete, either completed and failed at the same time, partial writing cannot succeed, and partial writing fails.

A simple understanding of the consistency and integrity of transactions means that we either live together or die together, we cannot live alone. (Like miserable love...^ _ ^)

Transaction isolation level in the database

Before understanding the transaction isolation level, let’s first understand the possible causes that often occur in the data Several situations in which business logic fails.

Dirty Reading

When a transaction is accessing data and has modified the data and has not yet submitted it to the database; at this time, another transaction also accesses the data and then uses this data.

For example: Zhang San’s bank account now has 1000, and now Zhang San deposits 200, then when Zhang San clicks submit, his wife (the hard-working Zhang San is saving pocket money for his wife) is shopping in the mall and spending money. 500. Zhang San checked the balance and found that it was only 500 (Zhang San was confused...). Then the two quarreled over 200. The above is what caused a family war due to excessive reading.

Non-repeatable reading

Non-repeatable reading: Read the same data multiple times within a transaction. Before this transaction ended, another transaction also accessed the data. Between the two reads of data by the first transaction, the data read by the first transaction may be different due to modifications by the second transaction. In this way, the data read twice within a transaction is different. (That is, the same data cannot be read)

Phantom reading

A transaction modifies the data in a table. This modification involves all data rows in the table. At the same time, The second transaction inserts a new row of data into the table. It will happen that the user who operates the first transaction finds that there are still unmodified data rows in the table. It was like a hallucination.

spring’s five isolation levels

ISOLATION_DEFAULT

represents the default isolation level of the underlying database. For most databases, the usual value is: ISOLATION _READ _COMMITTED

ISOLATION _READ _UNCOMMITTED

Indicates that a transaction can read data modified by another transaction but not yet committed, and cannot prevent dirty reads and non-repeatable reads.

ISOLATION _READ _COMMITTED

A transaction can only read data that has been submitted by another transaction. It can prevent dirty reads, but cannot prevent non-repeatable reads. (Recommended value in most cases)

ISOLATION _REPEATABLE _READ

A transaction can repeatedly execute a query multiple times during the entire process, and the records returned each time are the same. Even if there is new data between multiple queries to satisfy the query, these new records will be ignored. Can prevent dirty reads and non-repeatable reads.

ISOLATION _SERIALIZBLE

All transactions are executed one by one in sequence, so that there is no possibility of interference between transactions. It can prevent dirty reads, non-repeatable reads and phantom reads.

The propagation of transactions (spring provides seven)

refers to the relationship between transactions. For example, if a transaction contains another transaction, then the propagation is used to determine mutual execution.

TransationDefinition.PROPAGETION.REQUIRED

If a transaction currently exists, join the transaction; if there is currently no transaction, create a new transaction.
Default transaction in spring. Suitable for most situations.

TransationDefinition.PROPAGETION.REQUIRED_NEW

Create a new transaction. If a transaction currently exists, suspend the current transaction.
means creating a new transaction, which has nothing to do with the original transaction.

TransationDefinition.PROPAGETION.SUPPORTS

If a transaction currently exists, join the transaction; if there is currently no transaction, continue running in a non-transactional manner.
This method is very casual. If you don’t have it, you don’t have it. If you have it, you have it. It’s a bit of an indifferent attitude.

TransationDefinition.PROPAGATION.NOT_SUPPORTED

Run in a non-transactional manner. If a transaction currently exists, the current transaction will be suspended.
This method is very tough. If you don’t have it, you won’t have it. If you have it, you won’t support it. Just hang it up and ignore it.

TransationDefinition.PROPAGETION_NEVER

Run in a non-transactional manner and throw an exception if a transaction currently exists.
This method is more forceful. If there is no problem, there will be no problem. If there is a problem, an error will be reported. He declared to everyone: I never support affairs.

TransationDefinition.PROPAGETION_MANDATORY

If a transaction currently exists, join the transaction; if there is currently no transaction, throw an exception.
This method can be said to be the toughest. If there is no transaction, an error will be reported directly. It says to the whole world: I must have a transaction.

TransationDefinition.PROPAGETION_NESTED

If a transaction currently exists, create a transaction to run as a nested transaction of the current transaction; if there is currently no transaction, this value is equivalent to
TransationDefinition .PROPAGETION_REQUIRED

Declarative transaction

Use

Now look at springboot, if you use declarative transaction:

@Transactional
public void save(Object ob){

}

Just add @ on the method Transactional annotation methods can be managed by transactions.

Source code

Look at the source code of the annotation Transactional:

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {

@AliasFor("transactionManager")
String value() default "";


@AliasFor("value")
String transactionManager() default "";

Propagation propagation() default Propagation.REQUIRED;

Isolation isolation() default Isolation.DEFAULT;

int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;


boolean readOnly() default false;

Class<? extends Throwable>[] rollbackFor() default {};


String[] rollbackForClassName() default {};

Class<? extends Throwable>[] noRollbackFor() default {};


String[] noRollbackForClassName() default {};

}

Default value

readOnly: Whether it is only read-only. Both reading and writing are possible by default

timeout: Transaction timeout, no timeout by default

isolation: Transaction isolation level default: TransactionDefinition.ISOLATION_DEFAULT (see isolation level above)

propagation: Transaction propagation attribute default: TransactionDefinition.PROPAGATION_REQUIRED

Notes

• Annotations should only be applied to public methods

• Self-calling problem: If there is no annotated method in the class and calls an annotated method, then when the external method calls an unannotated method, the annotated method will not generate a transaction

The above is the detailed content of How to understand spring transactions and the use of declarative transactions. For more information, please follow other related articles on the PHP Chinese website!