This is the 26th day of my participation in Gwen Challenge

Declarative transaction

1. Transaction configuration

  1. Programmatic transaction
    • Programmers program transactions to control the code
  2. Declarative transaction
    • The transaction control code has been written by Spring. The programmer only needs to declare which methods need transaction control and how
  3. Declarative transactions are for methods under the ServiceImpl class
  4. The transaction manager is advice based
  5. Configure declarative transactions in the Spring configuration file
    1. The configuration of AOP
      • Because transactions are AOP-based, the pointcut is set here, but what pointcut is has nothing to do with the transaction
      • You can make the range of pointcuts a little bit bigger
      • Which method should use the tx tag above
    2. Configure the transaction manager
      • Spring – DataSourceTransactionManager class under the JDBC package
      • The purpose of a transaction is to flush data to a database.
    3. Configuration declaration transaction
      • Configure which methods to use transaction management, as well as many property Settings (such as how to handle transaction nesting)
    4. Configuring a Data Source
      • DataSouce (Mybatis – Spring integration)

      
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:context="http://www.springframework.org/schema/context"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd"
        default-autowire="byName"
        >
    <context:property-placeholder location="classpath:dbconfig.properties"/>    
    
	<! The transaction needs to commit data to the database at the end, so you need to configure the data source.
	<! -- Data source -->
    <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    	<property name="driverClassName" value="${jdbc.driver}"></property>
    	<property name="url" value="${jdbc.url}"></property>
    	<property name="username" value="${jdbc.username}"></property>
    	<property name="password" value="${jdbc.password}"></property>
    </bean>
	  <! -- SqlSessinFactory -->
    <bean id="factory" class="org.mybatis.spring.SqlSessionFactoryBean">
    	<property name="typeAliasesPackage" value="com.bjsxt.pojo"></property>
    </bean>
    <! -- Scanner -->
    <bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
    	<property name="basePackage" value="com.bjsxt.mapper"></property>
    	<property name="sqlSessionFactoryBeanName" value="factory"></property>
    </bean>
	
	<! -- Transaction manager -->
	<bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource" ref="dataSource"></property>
	</bean>	
	
	<! -- Config declare transaction -->
	<tx:advice id="" transaction-manager="txManager">
		<tx:attributes>
		<! Declare which method uses transaction control -->
			<! -- <tx:method name="insert"/> <tx:method name="insUsers"/> -->
			<! -- There may be many methods in the future, so you can use wildcards -->
			<! -- How to start with ins
			<tx:method name="ins*" propagation="REQUIRED"/>
			<tx:method name="del*" />
			<tx:method name="upd*" />
			<! -- Transaction read only -->
			<tx:method name="*" read-only="true"/>
		</tx:attributes>
	</tx:advice>
	
	<aop:config>
	<! < span style = "box-sizing: border-box; line-height: 22px; font-size: 13px! Important; word-break: break-word! Important;"
		<aop:pointcut expression="execution(* com.bjsxt.service.impl.*.*(..) )" id="mypoint"/>
		<aop:advisor advice-ref="" pointcut-ref="mypoint"/>
	</aop:config>
	</beans>
Copy the code

2. Transaction communication behavior

  1. Boolean readonly = “”
    • Whether a read-only transaction
    • If true, the database is told that the transaction is read-only. Data optimization, will be on

– If false(the default), the transaction needs to commit the transaction. 2. Code – namely to set the values of propagation properties

<tx:method name="ins*" propagation="REQUIRED"/>
Copy the code
  1. Propagation Controls transaction propagation behavior.
    1. How do you manage a transaction (new transaction? Execute in a transaction? Suspend transactions? The exception?)
    2. REQUIRED (default)
      • If there is a transaction, it is executed in the transaction. If there is no transaction, a new one is created
    3. SUPPORTS
      • If there is a transaction, it is executed in a transaction; if there is no transaction, it is executed in a non-transaction state
    4. MANDATORY
      • It must be executed within a transaction. If there is a transaction, it is executed within a transaction. If there is no transaction, an error is reported.
    5. REQUIRES_NEW
      • Must be executed in a transaction, if there is no transaction, create a new transaction, if there is a transaction, suspend the current transaction.
    6. NOT_SUPPORTED
      • If there is no transaction, execute normally. If there is a transaction, suspend the current transaction
    7. NEVER
      • It must be executed in the non-transaction state. If there is no transaction, it is executed normally. If there is a transaction, an error is reported.
    8. NESTED
      • Must be executed in transaction state. If there is no transaction, create a new transaction, and if there is one, create a nested transaction.

Transaction isolation level

  1. Problem solved
    • How to ensure the integrity of accessed data under multi-threaded or concurrent access.
  2. Dirty read
    • One transaction (A) reads uncommitted data from another transaction (B), and the data in another transaction may be changed. In this case, the data read by transaction A may be inconsistent with the data in the database. In this case, the data is considered as dirty data, and the process of reading dirty data is called dirty read
    • For example, A changed the name of the database from Zhang SAN to Li Si, and then put it in the cache without submitting it to the database; B reads the name Li Si from the cache, which is inconsistent with The name Zhang SAN in the database
  3. Unrepeatable read
    • This operation is used to modify data
      • The solution is to lock this data
    • Both reads are in the same transaction
    • After transaction A reads data, data B modifies the data, so data A reads data that is inconsistent with the database
    • For example, Zhang SAN went to the bank to check the account by 11 yuan, at the same time, Li Si withdrew 1 yuan; When Zhang SAN wanted to withdraw 11 yuan, he found that he could not withdraw it and the balance was insufficient. Therefore, it is necessary to set the data of money to be non-repeatable
  4. Phantom read
    • Add or delete
    • The result of two transactions
    • Transaction A queries the results according to certain criteria, and transaction B adds A new data that meets the criteria. When the data queried in transaction A is inconsistent with the data in the database, transaction A appears to have an illusion, which is called A phantom read.
      • The solution is to conditionally lock a table
  5. The isolation properties
    1. DEFAULT
      • The default value for the underlying database to automatically determine what isolation boundaries should be used
    2. READ_UNCOMMITTED
      • Can read uncommitted data, may appear dirty read, do not repeat read, phantom read
      • The most efficient
    3. READ_COMMITTED
      • Only committed data from other transactions can be read. Prevents dirty reads, which may be unrepeatable reads and phantom reads
    4. REPEATABLE_READ
      • Locks are added to read data to prevent other transactions from modifying the data and to prevent unrepeatable reads. Dirty read, phantom read may occur
    5. SERIALIZABLE
      • Queue operation to add a lock to the entire table. While one transaction is working on the data, another transaction waits for the transaction to complete before it can work on the table
      • The most secure
      • Least efficient

Four, rolled back

  1. Rollback-for = "Exception Type fully qualified path"
    • What exceptions do I need to roll back
    • Suggestion: Specify the value of this attribute.
  2. No - the rollback - for = ""
    • Do not roll back the transaction when some exception occurs