Spring @Transactional: aislamiento, propagación
¿ Alguien puede explicar los parámetros de aislamiento y propagación en la @Transactional
anotación mediante un ejemplo del mundo real?
Básicamente, ¿cuándo y por qué debería elegir cambiar sus valores predeterminados?
Buena pregunta, aunque no trivial de responder.
Propagación
Define cómo se relacionan las transacciones entre sí. Opciones comunes:
REQUIRED
: El código siempre se ejecutará en una transacción. Crea una nueva transacción o reutiliza una si está disponible.REQUIRES_NEW
: El código siempre se ejecutará en una nueva transacción. Suspende la transacción actual si existe.
El valor predeterminado para @Transactional
es REQUIRED
y esto suele ser lo que desea.
Aislamiento
Define el contrato de datos entre transacciones.
ISOLATION_READ_UNCOMMITTED
: Permite lecturas sucias.ISOLATION_READ_COMMITTED
: No permite lecturas sucias.ISOLATION_REPEATABLE_READ
: Si una fila se lee dos veces en la misma transacción, el resultado siempre será el mismo.ISOLATION_SERIALIZABLE
: Realiza todas las transacciones en una secuencia.
Los diferentes niveles tienen diferentes características de rendimiento en una aplicación multiproceso. Creo que si comprendes el concepto de lecturas sucias podrás seleccionar una buena opción.
Los valores predeterminados pueden variar entre diferentes bases de datos. Por ejemplo, para MariaDB es REPEATABLE READ
.
Ejemplo de cuándo puede ocurrir una lectura sucia:
thread 1 thread 2
| |
write(x) |
| |
| read(x)
| |
rollback |
v v
value (x) is now dirty (incorrect)
Por lo tanto, un valor predeterminado sensato (si se puede reclamar) podría ser ISOLATION_READ_COMMITTED
, que solo le permite leer valores que ya han sido confirmados por otras transacciones en ejecución, en combinación con un nivel de propagación de REQUIRED
. Luego podrá trabajar desde allí si su aplicación tiene otras necesidades.
Un ejemplo práctico de donde siempre se creará una nueva transacción al ingresar a la provideService
rutina y se completará al salir:
public class FooService {
private Repository repo1;
private Repository repo2;
@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
repo1.retrieveFoo();
repo2.retrieveFoo();
}
}
Si en su lugar hubiéramos usado REQUIRED
, la transacción permanecería abierta si ya estaba abierta al ingresar a la rutina. Tenga en cuenta también que el resultado de a rollback
podría ser diferente ya que podrían participar varias ejecuciones en la misma transacción.
Podemos verificar fácilmente el comportamiento con una prueba y ver cómo los resultados difieren con los niveles de propagación:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations="classpath:/fooService.xml")
public class FooServiceTests {
private @Autowired TransactionManager transactionManager;
private @Autowired FooService fooService;
@Test
public void testProvideService() {
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
fooService.provideService();
transactionManager.rollback(status);
// assert repository values are unchanged ...
}
Con un nivel de propagación de
REQUIRES_NEW
: esperaríamosfooService.provideService()
que NO se revirtiera ya que creó su propia subtransacción.REQUIRED
: esperaríamos que todo se revirtiera y que la tienda de respaldo no cambiara.
PROPAGACIÓN_REQUIRED = 0 ; Si DataSourceTransactionObject T1 ya está iniciado para el Método M1. Si para otro método M2 se requiere un objeto de transacción, no se crea ningún nuevo objeto de transacción. El mismo objeto T1 se utiliza para M2.
PROPAGACIÓN_MANDATORIA = 2 ; El método debe ejecutarse dentro de una transacción. Si no hay ninguna transacción en curso, se generará una excepción.
PROPAGATION_REQUIRES_NEW = 3 ; Si DataSourceTransactionObject T1 ya se inició para el Método M1 y está en progreso (ejecutando el método M1). Si otro método M2 comienza a ejecutarse, entonces T1 se suspende mientras dure el método M2 con el nuevo DataSourceTransactionObject T2 para M2. M2 se ejecuta dentro de su propio contexto de transacción.
PROPAGATION_NOT_SUPPORTED = 4 ; Si DataSourceTransactionObject T1 ya está iniciado para el Método M1. Si se ejecuta otro método M2 al mismo tiempo. Entonces M2 no debería ejecutarse dentro del contexto de la transacción. T1 se suspende hasta que se termine M2.
PROPAGACIÓN_NUNCA = 5 ; Ninguno de los métodos se ejecuta en el contexto de una transacción.
Un nivel de aislamiento: se trata de cuánto puede afectar una transacción a las actividades de otras transacciones concurrentes. Admite la coherencia y deja los datos de muchas tablas en un estado coherente. Implica bloquear filas y/o tablas en una base de datos.
El problema de las transacciones múltiples
Escenario 1 . Si la transacción T1 lee datos de la tabla A1 que fueron escritos por otra transacción simultánea T2. Si en el camino T2 se revierte, los datos obtenidos por T1 no son válidos. Por ejemplo, a=2 son datos originales. Si T1 lee a=1, eso fue escrito por T2. Si se revierte T2, entonces a=1 se revertirá a a=2 en DB. Pero ahora, T1 tiene a=1 pero en la tabla DB se cambia a a=2.
Escenario2 . Si la transacción T1 lee datos de la tabla A1. Si hay otra transacción concurrente (T2), actualice los datos en la tabla A1. Entonces los datos que ha leído T1 son diferentes a los de la tabla A1. Porque T2 ha actualizado los datos de la tabla A1. Por ejemplo, si T1 leyó a=1 y T2 actualizó a=2. Entonces a!=b.
Escenario 3 . Si la transacción T1 lee datos de la tabla A1 con un cierto número de filas. Si otra transacción concurrente (T2) inserta más filas en la tabla A1. El número de filas leídas por T1 es diferente de las filas de la tabla A1.
El escenario 1 se llama lecturas sucias.
El escenario 2 se denomina lecturas no repetibles.
El escenario 3 se llama lecturas fantasma.
Por lo tanto, el nivel de aislamiento es el grado en que se pueden prevenir los Escenario 1, Escenario 2 y Escenario 3 . Puede obtener un nivel de aislamiento completo implementando el bloqueo. Esto evita que se produzcan lecturas y escrituras simultáneas en los mismos datos. Pero afecta el rendimiento. El nivel de aislamiento depende de la cantidad de aislamiento que se requiere de una aplicación a otra.
ISOLATION_READ_UNCOMMITTED : permite leer cambios que aún no se han confirmado. Sufre del Escenario 1, Escenario 2, Escenario 3.
ISOLATION_READ_COMMITTED : permite lecturas de transacciones simultáneas que se han confirmado. Puede verse afectado por el Escenario 2 y el Escenario 3. Porque otras transacciones pueden estar actualizando los datos.
ISOLATION_REPEATABLE_READ : varias lecturas del mismo campo producirán los mismos resultados hasta que se cambie por sí solo. Puede verse afectado por el Escenario 3. Porque es posible que otras transacciones estén insertando los datos.
ISOLATION_SERIALIZABLE : El escenario 1, el escenario 2 y el escenario 3 nunca suceden. Es un aislamiento total. Se trata de un bloqueo total. Afecta el rendimiento debido al bloqueo.
Puedes probar usando:
public class TransactionBehaviour {
// set is either using xml Or annotation
DataSourceTransactionManager manager=new DataSourceTransactionManager();
SimpleTransactionStatus status=new SimpleTransactionStatus();
public void beginTransaction() {
DefaultTransactionDefinition Def = new DefaultTransactionDefinition();
// overwrite default PROPAGATION_REQUIRED and ISOLATION_DEFAULT
// set is either using xml Or annotation
manager.setPropagationBehavior(XX);
manager.setIsolationLevelName(XX);
status = manager.getTransaction(Def);
}
public void commitTransaction() {
if(status.isCompleted()) {
manager.commit(status);
}
}
public void rollbackTransaction() {
if(!status.isCompleted()) {
manager.rollback(status);
}
}
Main method {
beginTransaction();
M1();
If error(){
rollbackTransaction();
}
commitTransaction();
}
}
Puede depurar y ver el resultado con diferentes valores de aislamiento y propagación.
Otras respuestas dan explicaciones suficientes sobre cada parámetro; Sin embargo, usted solicitó un ejemplo del mundo real; aquí está el que aclara el propósito de las diferentes opciones de propagación :
Suponga que está a cargo de implementar un servicio de registro en el que se envía un correo electrónico de confirmación al usuario. Se le ocurren dos objetos de servicio, uno para inscribir al usuario y otro para enviar correos electrónicos, al que este último se llama dentro del primero. Por ejemplo algo como esto:/* Sign Up service */
@Service
@Transactional(Propagation=REQUIRED)
class SignUpService{
...
void SignUp(User user){
...
emailService.sendMail(User);
}
}
/* E-Mail Service */
@Service
@Transactional(Propagation=REQUIRES_NEW)
class EmailService{
...
void sendMail(User user){
try{
... // Trying to send the e-mail
}catch( Exception)
}
}
Es posible que haya notado que el segundo servicio es del tipo de propagación REQUIRES_NEW y, además, es probable que genere una excepción (servidor SMTP inactivo, correo electrónico no válido u otros motivos). Probablemente no desee que todo el proceso retroceda, como eliminar la información del usuario de una base de datos u otras cosas; por lo tanto, llama al segundo servicio en una transacción separada.
Volviendo a nuestro ejemplo, esta vez le preocupa la seguridad de la base de datos, por lo que define sus clases DAO de esta manera:/* User DAO */
@Transactional(Propagation=MANDATORY)
class UserDAO{
// some CRUD methods
}
Lo que significa que cada vez que se crea un objeto DAO y, por lo tanto, un acceso potencial a la base de datos, debemos asegurarnos de que la llamada se realizó desde uno de nuestros servicios, lo que implica que debe existir una transacción activa; de lo contrario, se produce una excepción. Por tanto la propagación es de tipo OBLIGATORIA .