Spring Declarative Transaction Basics

Spring's annotation transaction behavior, through @Transactional to customize transaction behavior.

Prerequisites: Transactions have four characteristics, ACID

    Atomicity: Atomicity , a transaction is an atomic operation, either all succeed or all fail.

    Consistency: Consistency, before the transaction operation is completed, all data must be consistent.

    Isolation: Isolation, transactions cannot affect each other.

    Durability: Durability , after the transaction is completed, the data must persist to the database.

Isolation, which determines the integrity of the transaction, may cause dirty reads, non-repeatable reads, and phantom reads when dealing with concurrent transactions.

        Dirty read : A transaction reads uncommitted updates from another transaction. 
        Non-repeatable read : A transaction reads the same row of data twice, but the data read twice is different. (for update) 
        phantom reading : a transaction executes two queries, but the second query has more data rows than the first query, and the transaction loses the modification of the newly added data rows (for insert)

        Isolation level:

        READ_UNCOMMITTED : The read is uncommitted, a record is modified in transaction A, but the transaction is not committed, but the modified record data is read in transaction B, resulting in dirty reads, non-repeatable reads, and phantom reads.

        READ_COMMITTED : The read has been committed, a record has been modified in transaction A, but the transaction has not been committed, and the modified record data cannot be read in transaction B. After transaction A is committed, transaction B has read the modified record. Data, which solves dirty reads, but can lead to non-repeatable reads and phantom reads.

        REPEATABLE_READ : Repeatable read. On the basis of READ_COMMITTED, when transaction A reads a record, transaction B will not allow to modify this record, which solves dirty reads and non-repeatable reads, but can lead to phantom reads.

        SERIALIZABLE : Serialization, transactions are executed sequentially at this level, which solves dirty reads, non-repeatable reads, and phantom reads, but has the highest overhead.

    Default level: oracle, sql server is READ_COMMITTED, mysql is REPEATABLE_READ.

propagation, which defines the life cycle of a transaction

        REQUIRED: When method A is called without a transaction, a new transaction is created. When another method B is called in method A, method B is added to the transaction. Method A and method B use the same transaction. If an exception occurs in method B, it needs to return When rolling, the entire transaction data is rolled back. Spring's default transaction propagation level.

        REQUIRED_NEW: For methods A and B, a new transaction will be created when the method is called regardless of whether there is a transaction, so that if method B is finally called in method A, transaction A is suspended, and transaction B is created, and an exception occurs in method B. Will cause the data of method A to be rolled back.

        NESTED: If an active transaction exists, run in a nested transaction. If there is no active transaction, it is executed according to the REQUIRED attribute, and only DataSourceTransactionManager is supported as the transaction manager. (It can be used for special purposes. If there is a problem with the execution of transaction B, after rolling back to a certain savepoint, execute C transaction after catching the exception externally, and continue to do other things after the savepoint, which is a very special purpose)

        SUPPORTS: When the method is called, a transaction is added to the current transaction, and if there is no transaction, it is performed in a non-transactional behavior.

        NOT_SUPPORTS: Force the method not to proceed in a transaction. If there is an active transaction, the current transaction will be suspended from the beginning of the method call to the end of the execution.

        NEVER: Forces the method not to proceed in a transaction, throws an exception if there is an active transaction.

        MANDATORY: Forces the method to execute in a transaction, throws an exception if there is no active transaction.

timeout, transaction expiration time.

readOnly, specifies whether the current transaction is a read-only transaction.

rollbackFor, specifies which exception or exceptions can cause the transaction to be rolled back.

noRollbackFor, specifies which exception or exceptions cannot cause the transaction to be rolled back.



        

        

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324849957&siteId=291194637