Comment l'isolement et la propagation @Transactional affectent-ils votre application Spring ?

Comprendre @Transactional : explorer l'isolement et la propagation

L'annotation @Transactional dans Spring joue un rôle crucial dans la gestion des transactions au sein de votre application. Il définit deux paramètres essentiels : l'isolement et la propagation.

Propagation

La propagation détermine la manière dont une transaction interagit avec les transactions existantes. Les options clés incluent :

• REQUIS :Le code s'exécute dans une transaction existante, en créant une nouvelle uniquement s'il n'en existe pas.
• REQUIRES_NEW : Une nouvelle transaction est toujours créée, suspendant une transaction existante si elle est présente.

La valeur par défaut est OBLIGATOIRE, ce qui convient dans la plupart des situations.

Isolation< /h3>

L'isolement définit les règles de visibilité des données entre les transactions. Plusieurs niveaux sont disponibles :

• ISOLATION_READ_UNCOMMITTED : Permet des "lectures sales" où les modifications apportées aux transactions non validées sont visibles.
• ISOLATION_READ_COMMITTED : Empêche les lectures incorrectes, mais peut autoriser les « lectures non répétables », lorsque les valeurs de plusieurs lectures diffèrent.
• ISOLATION_REPEATABLE_READ : Garantit la cohérence lors de la lecture deux fois de la même ligne, empêchant ainsi les lectures non répétables.
• ISOLATION_SERIALIZABLE : Sérialise les transactions en les exécutant les unes après les autres pour garantir l'atomicité.

Le niveau d'isolation optimal dépend des besoins spécifiques de votre application.

Quand ajuster les valeurs par défaut

Envisagez de modifier les valeurs par défaut lorsque :

• Vous souhaitez éviter des problèmes d'accès aux données spécifiques, tels que des lectures incorrectes. .
• Vous devez appliquer une cohérence absolue pour les récupérations de données.
• Vous rencontrez des problèmes de performances en raison d'un conflit de transactions élevé.

Exemple : niveaux d'isolement et Dirty Reads

Une lecture sale se produit lorsque le thread 1 écrit une valeur (x) et que le thread 2 lit (x) avant sa validation. Si le thread 1 annule ses modifications, le thread 2 contient désormais une valeur incorrecte.

Pour éviter les lectures sales, vous pouvez définir l'isolation sur ISOLATION_READ_COMMITTED ou ISOLATION_REPEATABLE_READ. Cela garantit que le thread 2 ne lit que les valeurs validées ou les instantanés cohérents.

Exemple de code : propagation de transaction

Considérez l'extrait de code suivant :

<code class="java">@Transactional(propagation=Propagation.REQUIRES_NEW)
public void provideService() {
    // Code that requires a new transaction
}</code>

Avec la propagation définie sur REQUIRES_NEW, une nouvelle transaction est toujours créée lors de la saisie de provideService() et validée à la sortie, quel que soit le contexte de transaction environnant.

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!