Paramètres d'isolement et de propagation dans @Transactional

Dans l'annotation @Transactional de Spring, deux paramètres critiques définissent le comportement des transactions de base de données : l'isolement et la propagation . Cet article explique quand et pourquoi vous devriez envisager d'ajuster leurs valeurs par défaut.

Propagation

La propagation définit les relations entre les transactions. Les options courantes incluent :

• REQUIRED : Exécute le code dans une transaction existante ou en crée une nouvelle s'il n'en existe pas.
• REQUIRES_NEW : Crée toujours une nouvelle transaction, suspendant toutes celles existantes.

Valeur par défaut : OBLIGATOIRE

Isolement

L'isolement définit le contrat de données entre les transactions. Il évite certaines incohérences de données en spécifiant le niveau de visibilité sur les modifications de données apportées par d'autres transactions. Les principaux niveaux d'isolement sont :

• READ_UNCOMMITTED : Aucune protection contre les lectures incorrectes.
• SERIALIZABLE : Isolation la plus forte, garantissant l'absence de conflits de données.

Valeur par défaut : Varie en fonction de la base de données (par exemple, REPEATABLE_READ pour MariaDB)

Exemple concret

Considérez le problème des lectures sales, où une transaction peut lire les modifications non validées apportées par une autre transaction.

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

Dans ce scénario, pour éviter les lectures incorrectes, vous pouvez définir le niveau d'isolement sur READ_COMMITTED et le niveau de propagation sur REQUIRED. Cette combinaison garantit que les transactions lisent uniquement les données qui ont été validées par d'autres transactions.

Personnalisation des transactions

Dans l'exemple suivant, la méthode provideService s'exécute toujours dans une nouvelle transaction, garantissant que les modifications apportées par d'autres tâches simultanées n'interfèrent pas avec son exécution :

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

Test du comportement des transactions

Pour vérifier le comportement des différents niveaux de propagation, vous pouvez utiliser un test Java :

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

Avec REQUIRES_NEW, fooService.provideService() ne serait pas annulé car il fonctionnait dans le cadre d'une transaction distincte. Avec REQUIRED, tout serait annulé.