Parámetros de aislamiento y propagación en @Transactional

En la anotación @Transactional de Spring, dos parámetros críticos definen el comportamiento de las transacciones de la base de datos: aislamiento y propagación . Este artículo explora cuándo y por qué debería considerar ajustar sus valores predeterminados.

Propagación

La propagación define cómo se relacionan las transacciones entre sí. Las opciones comunes incluyen:

• REQUIRED: Ejecuta el código dentro de una transacción existente o crea una nueva si no existe ninguna.
• REQUIRES_NEW: Siempre crea una nueva transacción, suspendiendo las existentes.

Valor predeterminado: REQUERIDO

Aislamiento

El aislamiento define el contrato de datos entre transacciones. Evita ciertas inconsistencias de datos al especificar el nivel de visibilidad de los cambios de datos realizados por otras transacciones. Los niveles de aislamiento clave son:

• READ_UNCOMMITTED: Sin protección contra lecturas sucias.
• SERIALIZABLE: Aislamiento más fuerte, lo que garantiza que no haya conflictos de datos.

Valor predeterminado: Varía según la base de datos (p. ej., REPEATABLE_READ para MariaDB)

Ejemplo del mundo real

Considere el problema de las lecturas sucias, donde una transacción puede leer cambios no confirmados realizados por otra transacción.

                                       Thread 1          Thread 2
                                               |              |
                                             Write(x)           |
                                               |              |
                                               |             Read(x)
                                               |              |
                                             Rollback           |
                                                 |             |
                                                   Value (x) is now dirty (incorrect)

En este escenario, para evitar lecturas sucias, puede establecer el nivel de aislamiento en READ_COMMITTED y el nivel de propagación en REQUIRED. Esta combinación garantiza que las transacciones solo lean los datos que han sido confirmados por otras transacciones.

Personalizar transacciones

En el siguiente ejemplo, el método provideService siempre se ejecuta dentro de una nueva transacción, lo que garantiza que los cambios realizados por otras tareas simultáneas no interfieran con su ejecución:

@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}

Prueba del comportamiento de las transacciones

Para verificar el comportamiento de diferentes niveles de propagación, puede utilizar una prueba de Java:

@Test
public void testProvideService() {
    TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
    fooService.provideService();
    transactionManager.rollback(status);
    // Assert repository values are unchanged ...
}

Con REQUIRES_NEW, fooService.provideService() no se revertiría ya que operaba dentro de una transacción separada. Con REQUIRED, todo se revertirá.