Spring @Transactional: aislamiento, propagación

¿ Alguien puede explicar los parámetros de aislamiento y propagación en la @Transactionalanotación mediante un ejemplo del mundo real?

Básicamente, ¿cuándo y por qué debería elegir cambiar sus valores predeterminados?

  thread 1   thread 2      
      |         |
    write(x)    |
      |         |
      |        read(x)
      |         |
    rollback    |
      v         v 
           value (x) is now dirty (incorrect)

public class FooService {
    private Repository repo1;
    private Repository repo2;

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

@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 ... 
}

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 .