Spring transaction isolation and transaction Propagation

Spring transaction isolation and transaction Propagation

Detailed description and comparison of Spring transaction isolation and transaction Propagation

Spring is the administrator of SSH and is responsible for managing other frameworks and coordinating the work of various parts. Let's take a look at Spring transaction management today. Spring transaction management is divided into declarative and programming. Declarative configuration is performed in the Spring configuration file; programmatic configuration is written into the code by annotation.

The transaction configuration in the Spring configuration file is always composed of three parts: DataSource, TransactionManager, and proxy mechanism. In any configuration method, the agent mechanism is changed. DataSource and TransactionManager only change according to the data access method. For example, when Hibernate is used for data access, DataSource is actually SessionFactory, and the implementation of TransactionManager is HibernateTransactionManager.

Transaction isolation level of spring

• ISOLATION_DEFAULT: use the default database isolation level.
• ISOLATION_READ_UNCOMMITTED: allows reading changed uncommitted data, which may lead to dirty reads, non-repeated reads, and Phantom reads.
• ISOLATION_READ COMMITTED: Allows concurrent transactions to be read after being COMMITTED, which can avoid dirty reads and may lead to repeated and Phantom reads.
• ISOLATION_REPEATABLE_READ: The read results of the same field are consistent multiple times, which can lead to phantom read.
• ISOLATION_SERIALIZABLE: fully complies with ACID principles to ensure that dirty reads, non-repeated reads, and Phantom reads are not performed.
  

You can adopt an appropriate isolation level based on your system's requirements for data, because isolation involves locking records in the database, the stricter the requirements on positive data, and the worse the concurrency performance.

Spring transaction Propagation Behavior

• The Propagation Behavior of spring transactions refers to how transactions operate when one method calls another method.
• PROPAGATION_MANDATORY: This method must run in a transaction. If the current transaction does not exist, an exception is thrown.
• PROPAGATION_NESTED: if a transaction exists, the method runs in a nested transaction. Nested transactions can be committed and rolled back independently from the current transaction. If no transaction exists, a new transaction starts. Each Vendor's support for such promotional activities is uneven.
• PROPAGATION_NEVER: the current method should not run in a transaction. If a transaction exists, an exception is thrown.
• PROPAGATION_NOT_SUPPORTED: the current method should not run in a transaction. If a transaction is running, it will be suspended during the running of the method.
• PROPAGATION_REQUIRED: This method must run in a transaction. If a transaction is running, this method runs in this transaction. Otherwise, a new transaction is started.
• PROPAGATION_REQUIRES_NEW: The method must run in its own transaction. It starts a new transaction. If an existing transaction is running, it will be suspended during the running of this method.
• PROPAGATION_SUPPORTS: the current method does not need a transaction processing environment, but if a transaction is already running, this method can also be run in this transaction.

The above is an example of Spring transaction isolation and transaction propagation. If you have any questions, please leave a message or go to the community on this site for discussion. Thank you for reading this article and hope to help you. Thank you for your support for this site!