Parâmetros de isolamento e propagação em @Transactional

Na anotação @Transactional do Spring, dois parâmetros críticos definem o comportamento das transações de banco de dados: isolamento e propagação . Este artigo explora quando e por que você deve considerar ajustar seus valores padrão.

Propagação

A propagação define como as transações se relacionam entre si. As opções comuns incluem:

• REQUIRED: Executa o código em uma transação existente ou cria uma nova se não existir nenhuma.
• REQUIRES_NEW: Sempre cria uma nova transação, suspendendo quaisquer transações existentes.

Valor padrão: OBRIGATÓRIO

Isolamento

O isolamento define o contrato de dados entre as transações. Ele evita certas inconsistências de dados, especificando o nível de visibilidade das alterações de dados feitas por outras transações. Os principais níveis de isolamento são:

• READ_UNCOMMITTED: Nenhuma proteção contra leituras sujas.
• SERIALIZÁVEL: Isolamento mais forte, garantindo nenhum conflito de dados.

Valor padrão: Varia dependendo do banco de dados (por exemplo, REPEATABLE_READ para MariaDB)

Exemplo do mundo real

Considere a questão das leituras sujas, onde uma transação pode ler alterações não confirmadas feitas por outra transação.

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

Neste cenário, para evitar leituras sujas, você pode definir o nível de isolamento como READ_COMMITTED e o nível de propagação como REQUIRED. Essa combinação garante que as transações leiam apenas dados que foram confirmados por outras transações.

Personalizando transações

No exemplo a seguir, o método provideService sempre é executado dentro de uma nova transação, garantindo que quaisquer alterações feitas por outras tarefas simultâneas não interfiram em sua execução:

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

Testando o comportamento da transação

Para verificar o comportamento de diferentes níveis de propagação, você pode usar um teste Java:

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

Com REQUIRES_NEW, fooService.provideService() não seria revertido, pois operava em uma transação separada. Com REQUIRED, tudo seria revertido.