- • 1.PROPAGATION_REQUIRED — Supports the current transaction, and creates a new one if there is none. This is the most common choice. • 2.PROPAGATION_SUPPORTS – The current transaction is supported, and if there is no current transaction, it is executed non-transactionally. • 3.PROPAGATION_MANDATORY – The current transaction is supported, and an exception is thrown if there is none. • 4.PROPAGATION_REQUIRES_NEW — Create a transaction, and suspend the current transaction if one exists. • 5.PROPAGATION_NOT_SUPPORTED – Executes an operation in a non-transactional manner, and suspends the current transaction if one exists. • 6.PROPAGATION_NEVER — Executes non-transactionally, throwing an exception if a transaction currently exists. • 7.propagation_NESTED – Executes within a nested transaction if a transaction currently exists. If there are no transactions currently, an operation similar to PROPAGATION_REQUIRED is performed. Note: The two commonly used transaction propagation attributes are 1 and 4, PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW
- Five isolation level: a PlatfromTransactionManager ISOLATION_DEFAULT this is the default isolation level, using the database to the default transaction isolation level. The other four correspond to JDBC isolation levels; ISOLATION_READ_UNCOMMITTED This is the lowest isolation level for a transaction and allows another transaction to see the uncommitted data of this transaction. This isolation level produces dirty reads, non-repeatable reads, and phantom reads. ISOLATION_READ_COMMITTED Ensures that data modified by one transaction is committed before it can be read by another transaction. Another transaction cannot read uncommitted data from that transaction. This transaction isolation level avoids dirty reads, but non-repeatable and phantom reads may occur. The ISOLATION_REPEATABLE_READ transaction isolation level prevents dirty, non-repeatable reads. But illusionary reading can occur. In addition to ensuring that one transaction cannot read uncommitted data from another transaction, it also ensures that the following situation (unrepeatable reads) is avoided. ISOLATION_SERIALIZABLE This is the most expensive but reliable transaction isolation level. Transactions are processed for sequential execution. In addition to preventing dirty read, not repeat read, but also avoid phantom read. Key words: 1) Phantom read: when transaction 1 reads the record, transaction 2 adds the record and commits it. When transaction 1 reads the record again, transaction 2 can see the new record; 2) Non-repeatable read: when transaction 1 reads the record, transaction 2 updates the record and commits it. When transaction 1 reads the record again, the modified record of transaction 2 can be seen. 3) Dirty read: Transaction 1 updated the record but did not commit, transaction 2 read the updated row, then transaction T1 rolled back, and now T2 read invalid. Dirty read: a transaction reads data from an uncommitted transaction. Non-repeatable read: a transaction reads a row of data from a table. One transaction reads the data after another transaction commits. Virtual read: a transaction that reads data inserted by another transaction, causing inconsistent reads (INSERT)
Transaction rolled back because it has been marked as rollback-only When multiple method transactions are nested in a program, the child method throws a runtime exception and the parent method catches an exception. When the parent method completes the commit transaction, the child method throws an exception and sets the transaction to rollback-only. Transaction Rolled back because it has been marked as rollback-only error message is displayed. The exception is caused by the fact that the submethod transaction propagation level REQUIRES the Spring transaction default level (REQUIRES). In Spring, the two transactions are combined into one, and the transaction is committed only when each submethod in the entire method has completed execution. The parent method commits the transaction with a rollbackonly error message. The submethod transaction is defined as (REQUIRES_NEW). When the submethod throws an exception, the submethod transaction rolls back and the program runs normally.
Original link: