spring transaction management - transaction propagation and transaction isolation

1. By default, spring transactions will only be rolled back when an uncaptured runtimeexcetpion occurs.
If the exception is caught with try catch, the transaction will not be rolled back because the exception has been caught.
To achieve the effect of rollback, there are two solutions:
Method 1: You need to add throw new runtimeexcetpion() to the last line of the catch block;
     (throw new Excetpion() will not roll back the transaction, because it is not a runtime exception , like the null pointer exception will be rolled back, because it is a subclass of the runtime exception class, which belongs to the runtime exception)
Method 2: Or add TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); to the catch to
     manually roll back the transaction.

Note: The transaction exception rollback can be set. For example, if the exception rollback of the transaction configuration is set to java.lang.Exception, when a java.lang.Exception exception is thrown, the transaction will be rolled back. If not configured, the default is Runtime exception:
<tx:method name="update*" propagation="REQUIRED" rollback-for="java.lang.Exception"/>
Transaction propagation

2. Meaning of transaction suspension: Transaction suspension and transaction recovery The operations done by time will not be managed, and commit will not submit these changes.

3. Several propagation characteristics of transactions


       REQUIRED: The business method needs to run in a container. If the method is running, it is already in a transaction, then join the transaction, otherwise create a new transaction by yourself.

       NOT_SUPPORTED: The declared method does not require a transaction. If the method is not associated with a transaction, the container will not open a transaction for it. If the method is called in a transaction, the transaction will be suspended. After the call ends, the original transaction will resume execution.

       REQUIRES_NEW: Regardless of whether there is a transaction, this method initiates a new transaction for itself. If the method is already running in a transaction, the original transaction is suspended and a new transaction is created.

       MANDATORY: This method can only be executed in an existing transaction, and business methods cannot initiate their own transactions. If called without a transaction, the container throws an exception.

       SUPPORTS: The method is called in a transaction, and the method becomes part of the transaction. If the method is called outside the scope of the transaction, the method is executed without a transaction.

       NEVER: The method must never be executed within the scope of a transaction. If so, throw an exception. Only the method is not associated with any transaction, it will execute normally.

       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. It uses a single transaction with multiple savepoints that can be rolled back. The rollback of the inner transaction does not affect the outer transaction. It only works on the DataSourceTransactionManager transaction manager.

       NESTED is more difficult to understand, such as public void a(){b();c();d();} public void c(){} , the a method is the REQUIRED propagation attribute, the c method is the NESTED propagation attribute,
                 Call the c method directly. The transaction of the c method is equivalent to REQUIRED. If the a method is called, the c method is called. At this time, the c method reports an error, which will only cause the changes of the c method to not be submitted, but the changes in the bd can still be submitted. If b reports an error or d method reports an error, the changes made by bcd cannot be committed.



4. The difference between method invocation and transaction creation between services: in
   the same service class, invocation between methods will not create a new transaction, even if the method propagation attribute is called REQUIRES_NEW, it will not be created. new business.
   Whether a method is called between different services creates a new transaction or not depends on the transaction propagation properties of the method, for example: REQUIRED will not create a new transaction, REQUIRES_NEW will create a new transaction


5. How to ensure that there are methods between the service layers when calling each other It also guarantees either all success or all failure.
Solution: There is only one transaction in the process of calling each other in the service method, so there will be no problem if all additions, deletions and changes are set to REQUIRED. The configuration is as follows

  <!-- Transaction Manager-->
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
  <property name="sessionFactory">
<ref bean="sessionFactory">< /ref>
</property>
</bean>


<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="save*"   propagation="REQUIRED" />
<tx:method name="update*" propagation="REQUIRED" />
<tx:method name="delete*" propagation="REQUIRED" />
<tx:method name="*"  read-only="true" />
</tx:attributes>
</tx:advice> 

<!-- 那些类的哪些方法参与事务 -->
<aop:config>
<aop:pointcut id="allServiceMethod" expression="execution(* service.*.*(..))" />
<aop:advisor pointcut-ref="allServiceMethod" advice-ref="txAdvice"/>       1. ISOLATION_DEFAULT: This is the default isolation level of a PlatfromTransactionManager, using the database default transaction isolation level. Spring transaction isolation level Transaction isolation
</aop:config>




         The other four correspond to the isolation level of JDBC
      2. ISOLATION_READ_UNCOMMITTED: This is the lowest isolation level of the transaction, which allows a transaction to see the uncommitted data of the transaction.
         This isolation level produces dirty reads, non-repeatable reads and phantom reads.
     3. ISOLATION_READ_COMMITTED: To ensure that the data modified by one transaction can only be read by another transaction after it is committed. Another transaction cannot read the uncommitted data of the transaction
     4. ISOLATION_REPEATABLE_READ: This transaction isolation level can prevent dirty reads and non-repeatable reads. However, phantom reads may occur.
         In addition to ensuring that a transaction cannot read uncommitted data of another transaction, it also ensures that the following situation (non-repeatable read) is avoided.
     5. ISOLATION_SERIALIZABLE This is the most expensive but most reliable transaction isolation level. Transactions are processed for sequential execution.
        In addition to preventing dirty reads, non-repeatable reads, it also avoids phantom reads.

  Dirty read: Refers to when a transaction is accessing data and modifying the data, and the modification has not been submitted to the database, at this time, another transaction also accesses the data and then uses the data. Because this data is uncommitted data, the data read by another transaction is dirty data, and operations based on dirty data may be incorrect.
Non-repeatable read: Refers to reading the same data multiple times within a transaction. While this transaction is not over, another transaction also accesses the same data. Then, between two reads of data in the first transaction, due to the modification of the second transaction, the data read twice by the first transaction may be different. In this way, the data read twice in a transaction is different, so it is called non-repeatable read.
Illusionary reading: Refers to a phenomenon that occurs when transactions are not executed independently, for example, the first transaction modifies data in a table, and this modification involves all data rows in the table. At the same time, the second transaction also modifies the data in this table by inserting a new row of data into the table. Then, the user who operates the first transaction will find that there are no modified data rows in the table in the future, as if an illusion has occurred.

Configuration example:
<tx:advice id="txAdvice" transaction-manager="transactionManager" >
<tx:attributes>
<tx:method name="save*" propagation="REQUIRED" />
<tx:method name="update*" propagation="REQUIRED" />
<tx:method name="delete*" propagation="REQUIRED" />
<tx:method name="*" read-only="true" isolation ="READ_COMMITTED"/>
</tx:attributes>
</tx:advice>