Quand et pourquoi devriez-vous ajuster les paramètres d'isolation et de propagation par défaut dans @Transactional ?

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 la manière dont les transactions sont liées les unes aux autres. 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 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 sales.
• 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 du monde réel

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 sales, vous pouvez définir le niveau d'isolement sur READ_COMMITTED et le niveau de propagation à REQUIS. 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 au sein d'une nouvelle transaction, garantissant que les modifications apportées par d'autres tâches simultanées n'interfèrent pas avec son exécution :

<code class="java">@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    repo1.retrieveFoo();
    repo2.retrieveFoo();
}</code>

Test du comportement de la transaction

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

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

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!