Directorio de artículos
1. Asuntos
1.1 Características de las transacciones
La transacción tiene cuatro características de ACID:
Atomicidad : Una transacción es una unidad de trabajo indivisible. Las operaciones en la transacción ocurren todas o no tienen
consistencia (Consistencia) : Después de que se completa la transacción, la integridad de los datos debe mantener un
aislamiento consistente (Aislamiento) : Cuando varios usuarios acceden a la base de datos al mismo tiempo, la transacción de un usuario no puede ser interferida por las transacciones de otros usuarios, y los datos entre múltiples transacciones simultáneas deben aislarse entre sí
. Durabilidad : una vez que se envía una transacción, afectará los datos en la base de datos. El cambio debe ser permanente, incluso si la base de datos falla, no debe tener ningún impacto en ella.
Si se produce una excepción / error en cualquier lugar durante todo el proceso de ejecución de la transacción, la transacción se revertirá y el estado de los datos después de la reversión será exactamente el mismo que antes de la ejecución de la transacción.
1.2 Nivel de aislamiento de transacciones
El nivel de aislamiento se refiere al grado de aislamiento entre varias transacciones concurrentes. Hay cinco constantes que representan los niveles de aislamiento definidos en la interfaz TransactionDefinition:
| Nivel de aislamiento de transacciones de la interfaz TransactionDefinition | descripción |
|---|---|
| ISOLATION_DEFAULT | El valor predeterminado indica que se utiliza el nivel de aislamiento predeterminado de la base de datos subyacente. Para la mayoría de las bases de datos, este valor suele ser TransactionDefinition.ISOLATION_READ_COMMITTED |
| ISOLATION_READ_UNCOMMITTED | El nivel de aislamiento significa que una transacción puede leer datos modificados por otra transacción pero aún no confirmados. Este nivel no puede evitar lecturas sucias, lecturas no repetibles y lecturas fantasmas , por lo que este nivel de aislamiento rara vez se usa. |
| ISOLATION_READ_COMMITTED | Este nivel de aislamiento significa que una transacción solo puede leer datos que han sido confirmados por otra transacción. Puede evitar lecturas sucias , que es el valor recomendado en la mayoría de los casos. |
| ISOLATION_REPEATABLE_READ | Este nivel de aislamiento significa que una transacción puede ejecutar una consulta varias veces durante todo el proceso, y los registros devueltos cada vez son los mismos. Este nivel puede evitar lecturas sucias y lecturas no repetibles . |
| ISOLATION_SERIALIZABLE | Todas las transacciones se ejecutan una por una, y no hay absolutamente ninguna posibilidad de interferencia entre transacciones. Este nivel puede evitar lecturas sucias, lecturas no repetibles y lecturas fantasma . Pero esto afectará seriamente el desempeño del programa . Normalmente tampoco se utiliza este nivel. |
1.3 Las características de propagación de las transacciones
Características de propagación de la transacción: si ya existe un contexto de transacción antes de iniciar la transacción actual, existen varias opciones para especificar el comportamiento de ejecución de un método transaccional.
Estas constantes que representan el comportamiento de propagación definido en TransactionDefinition
| Constante de comportamiento de propagación de transacciones TransactionDefinition | descripción |
|---|---|
| PROPAGATION_REQUIRED | Defaults. Si actualmente hay una transacción, únase a la transacción; si no hay una transacción actual, cree una nueva transacción |
| PROPAGATION_REQUIRES_NEW | Cree una nueva transacción, si hay una transacción actual, luego suspenda la transacción actual |
| PROPAGATION_SUPPORTS | Si actualmente hay una transacción, únase a la transacción; si no hay una transacción actual, continúe ejecutándose de manera no transaccional |
| PROPAGATION_NOT_SUPPORTED | Ejecutar en modo no transaccional. Si hay una transacción actualmente, la transacción actual se suspende. |
| PROPAGATION_NEVER | Ejecutar en modo no transaccional. Si hay una transacción actualmente, se lanza una excepción. |
| PROPAGATION_MANDATORY | Si hay una transacción actualmente, se unirá a la transacción; si no hay ninguna transacción actualmente, se lanzará una excepción. |
| PROPAGATION_NESTED | Si hay una transacción actualmente, se crea una transacción para que se ejecute como una transacción anidada de la transacción actual; si no hay ninguna transacción actualmente, el valor es equivalente a TransactionDefinition.PROPAGATION_REQUIRED. |
1.4 Reglas de reversión de transacciones
En la configuración predeterminada, Spring revierte la transacción solo cuando la excepción lanzada es una excepción no comprobada en tiempo de ejecución, es decir, la excepción lanzada es una subclase de RuntimeException (los errores también harán que la transacción retroceda), y se lanza una excepción marcada. No hará que la transacción se revierta . Puede configurar explícitamente qué excepciones se lanzan para revertir la transacción, incluidas las excepciones marcadas. También puede definir claramente aquellas transacciones que no se revierten cuando se lanzan excepciones. También puede utilizar mediante programación el método setRollbackOnly () para indicar que una transacción debe revertirse. La única operación que puede realizar después de llamar a setRollbackOnly () es revertir.
2. Gestión de transacciones de primavera
La gestión de transacciones de Spring se divide en gestión programática de transacciones y gestión declarativa de transacciones.
2.1 Gestión declarativa de transacciones
Las transacciones declarativas se basan en AOP. Su esencia es interceptar antes y después del método , luego crear o agregar una transacción antes de que comience el método de destino, y enviar o revertir la transacción de acuerdo con la ejecución después de que se ejecute el método de destino.
La mayor ventaja de la gestión declarativa de transacciones es que no es necesario gestionar las transacciones a través de la programación, por lo que no es necesario agregar código de procesamiento de transacciones al código de lógica empresarial. Solo necesita declarar las reglas de transacción relevantes para aplicar las reglas de transacción a la lógica empresarial.
//如果不想某个异常进行事务处理
@Transactional(rollbackFor=RuntimeException.class)//不对RuntimeException回滚生效
@Transactional(rollbackFor=Exception.class)// 不对Exception回滚生效
La gestión de transacciones declarativas de Spring se puede lograr de dos formas:
- Basado en la anotación @Transactional .
- Enfoque basado en XML
2.1.1 Basado en la anotación @Transactional
Agregue la anotación @Transactional directamente al método de la capa de Servicio.
Configure el administrador de transacciones en applicationContext.xml
<!-- 事务管理器 完成手动事务管理-->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<!--打开注解事务管理-->
<tx:annotation-driven transaction-manager="transactionManager"/>
Realización del caso: https://github.com/strive-xgf/SSM/commit/d855985d82db5d969a9e9820fe0686f8ce9341bc
2.1.2 Enfoque basado en XML
- La gestión de transacciones declarativas basada en XML se realiza mediante la configuración de declaraciones relevantes de reglas de transacción en el archivo de configuración. El marco de Spring proporciona un espacio de nombres tx para configurar transacciones .
- tx: elemento de aviso para configurar la notificación de la transacción . Al configurar el elemento tx: advice, generalmente necesita especificar los atributos id y transaction-manager, donde el atributo id es un identificador único en el archivo de configuración y el atributo transaction-manager especifica el administrador de transacciones.
- El subelemento tx: atributos se puede configurar con varios subelementos tx: método para especificar los detalles de la transacción.
- Después de que el elemento tx: advice está configurado con procesamiento de transacciones mejorado, puede escribir la configuración de AOP para permitir que Spring genere automáticamente un proxy para el objeto de destino.
Necesita configurar transacciones y notificaciones en applicationContext.xml
Realización del caso: https://github.com/strive-xgf/SSM/commit/61cae51d9a69975ab2caa75249c84d484accff83
2.2 Gestión programática de transacciones
La gestión de transacciones mediante programación basada en la API subyacente consiste en realizar el procesamiento de transacciones mediante programación de acuerdo con las tres interfaces principales de PlatformTransactionManager, TransactionDefinition y TransactionStatus. Spring recomienda usar TransactionTemplate . Llame explícitamente a beginTransaction () , commit () , ** rollback () ** y otros métodos relacionados con transacciones
en el código , que es la gestión programática de transacciones.
El método execute () de TransactionTemplate tiene un parámetro de tipo de interfaz TransactionCallback. La interfaz define un método doInTransaction (), que generalmente implementa la interfaz TransactionCallback en forma de una clase interna anónima y escribe código de lógica empresarial en su método doInTransaction (). Las reglas predeterminadas de confirmación y reversión de transacciones se pueden usar aquí, y no es necesario llamar explícitamente a ninguna API de transacción en el código comercial. El método doInTransaction () tiene un parámetro de tipo TransactionStatus. El método setRollbackOnly () de este parámetro se puede llamar en cualquier lugar del método para marcar la transacción como una reversión para realizar la reversión de la transacción.
De acuerdo con las reglas predeterminadas, si se lanza una excepción sin marcar durante la ejecución del método de devolución de llamada, o se llama explícitamente al método setRollbackOnly (), la transacción se revierte; si la transacción se completa o se lanza una excepción marcada, la transacción se confirma .
Realización del caso: https://github.com/strive-xgf/SSM/commit/fe39a52b5d2f6c692db7ed0a373c6e327cb8a267