Comment comprendre les transactions Spring et l'utilisation des transactions déclaratives

Le contenu de cet article explique comment comprendre les transactions Spring et l'utilisation des transactions déclaratives, y compris le niveau d'isolement des éléments dans la base de données. J'espère que les amis dans le besoin pourront s'y référer. vous être utile.

L'utilisation des transactions printanières et des transactions déclaratives

(Étudiants, commencez à réviser les connaissances en bases de données données aux enseignants par l'université !!)

Transaction : unité d'exécution de programme (unité) qui accède et éventuellement met à jour divers éléments de données dans la base de données.

Les transactions ont quatre attributs : (ACID)

Atomicité : Une transaction est une unité de travail indivisible, et toutes les opérations incluses dans la transaction sont soit effectuées, soit aucune.

Cohérence ; une transaction doit faire passer la base de données d'un état de cohérence à un autre état de cohérence. La cohérence et l'atomicité sont étroitement liées.

Isolement : L'exécution d'une transaction ne peut pas être interférée par d'autres choses. Autrement dit, les opérations internes et les données utilisées dans une transaction sont isolées des autres transactions simultanées et les transactions exécutées simultanément ne peuvent pas interférer les unes avec les autres.

Persistance : La persistance, également connue sous le nom de permanence, signifie qu'une fois qu'une transaction est soumise, ses modifications apportées aux données de la base de données doivent être permanentes.

Objectif de la transaction : Maintenir la cohérence et l'intégrité des données.

Cohérence : le statut des données d'une chaîne commerciale est cohérent et ne peut pas être partiellement modifié ni partiellement inchangé.

Intégrité : Les données d'une chaîne commerciale sont complètes, soit terminées et échouées en même temps, l'écriture partielle ne peut pas réussir et l'écriture partielle échoue.

Une compréhension simple de la cohérence et de l'intégrité des affaires est que soit nous vivons ensemble, soit nous mourons ensemble, nous ne pouvons pas vivre seuls. (Comme un amour misérable...^ _ ^)

Niveau d'isolement des transactions dans la base de données

Avant de comprendre le niveau d'isolement des transactions, comprenons d'abord les causes possibles qui se produisent souvent dans les données Plusieurs situations dans lequel la logique métier échoue.

Lecture sale

Lorsqu'une transaction accède aux données et a modifié les données et ne les a pas encore soumises à la base de données à ce moment-là, une autre transaction accède également aux données et utilise ensuite ces données ; .

Par exemple : le compte bancaire de Zhang San en compte maintenant 1 000, et maintenant Zhang San en a déposé 200, puis lorsque Zhang San clique sur Soumettre, sa femme (le travailleur acharné Zhang San économise de l'argent de poche pour sa femme) est faire du shopping dans le centre commercial et dépenser 500 $. Zhang San a vérifié le solde et a constaté qu'il n'y avait que 500 (Zhang San était confus...). Ensuite, les deux se sont disputés à plus de 200. C’est ce qui précède qui a provoqué une guerre familiale due à une lecture excessive.

Lecture non répétable

Lecture non répétable : lisez les mêmes données plusieurs fois au cours d'une transaction. Avant la fin de cette transaction, une autre transaction a également accédé aux données. Entre les deux lectures de données par la première transaction, les données lues par la première transaction peuvent être différentes du fait des modifications apportées par la seconde transaction. De cette manière, les données lues deux fois au sein d’une transaction sont différentes. (C'est-à-dire que les mêmes données ne peuvent pas être lues)

Lecture fantôme

Une transaction modifie les données d'une table, et cette modification implique toutes les lignes de données de la table en même temps. la deuxième transaction insère une nouvelle ligne de données dans la table. Il arrivera que l'utilisateur qui effectue la première transaction constate qu'il reste encore des lignes de données non modifiées dans la table. C'était comme une hallucination.

les cinq niveaux d'isolement de Spring

ISOLATION_DEFAULT

représente le niveau d'isolement par défaut de la base de données sous-jacente. Pour la plupart des bases de données, la valeur habituelle est : ISOLATION _READ _COMMITTED

ISOLATION _READ _UNCOMMITTED

indique qu'une transaction peut lire des données modifiées par une autre transaction mais pas encore validées, et ne peut pas empêcher les lectures sales et les lectures non répétables.

ISOLATION _READ _COMMITTED

Une transaction ne peut lire que les données qui ont été soumises par une autre transaction, ce qui peut empêcher les lectures sales, mais ne peut pas empêcher les lectures non répétables. (Valeur recommandée dans la plupart des cas)

ISOLATION _REPEATABLE _READ

Une transaction peut exécuter une requête de manière répétée plusieurs fois pendant tout le processus, et les enregistrements renvoyés à chaque fois sont les mêmes. Même s'il existe de nouvelles données entre plusieurs requêtes pour satisfaire la requête, ces nouveaux enregistrements seront ignorés. Peut empêcher les lectures sales et les lectures non répétables.

ISOLATION _SERIALIZBLE

Toutes les transactions sont exécutées une par une dans l'ordre, de sorte qu'il n'y a aucune possibilité d'interférence entre les transactions. Il peut empêcher les lectures sales, les lectures non répétables et les lectures fantômes.

La propagation des transactions (spring en propose sept)

fait référence à la relation entre les transactions. Par exemple, si une transaction contient une autre transaction, alors la propagation est utilisée pour déterminer l'exécution de l'autre. .

TransationDefinition.PROPAGETION.REQUIRED

Si une transaction existe actuellement, rejoignez la transaction s'il n'y a pas de transaction actuellement, créez une nouvelle transaction ;

Transaction par défaut au printemps. Convient à la plupart des situations.

TransationDefinition.PROPAGETION.REQUIRED_NEW

Créer une nouvelle transaction Si une transaction existe actuellement, suspendez la transaction en cours.

Cela signifie créer une nouvelle transaction, qui n'a rien à voir avec la transaction originale.

TransationDefinition.PROPAGETION.SUPPORTS

Si une transaction existe actuellement, rejoignez la transaction ; s'il n'y a actuellement aucune transaction, continuez à l'exécuter de manière non transactionnelle.
Cette méthode est très décontractée. Si vous ne l'avez pas, vous ne l'avez pas. Si vous l'avez, vous l'avez. C'est une attitude un peu indifférente.

TransationDefinition.PROPAGATION.NOT_SUPPORTED

Exécuter de manière non transactionnelle Si une transaction existe actuellement, la transaction en cours sera suspendue.
Cette méthode est très difficile. Si vous ne l'avez pas, vous ne l'aurez pas. Si vous l'avez, vous ne la soutiendrez pas.

TransationDefinition.PROPAGETION_NEVER

Exécuter de manière non transactionnelle et lancer une exception si une transaction existe actuellement.
Cette méthode est plus énergique. S'il n'y a pas de problème, il n'y aura pas de problème. S'il y a un problème, une erreur sera signalée à tout le monde : je ne soutiens jamais les affaires.

TransationDefinition.PROPAGETION_MANDATORY

S'il y a actuellement une transaction, rejoignez la transaction ; s'il n'y a pas de transaction actuellement, lancez une exception.
Cette méthode peut être considérée comme la plus difficile. S'il n'y a pas de transaction, une erreur sera signalée directement au monde entier : je dois avoir une transaction.

TransationDefinition.PROPAGETION_NESTED

Si une transaction existe actuellement, créez une transaction à exécuter comme une transaction imbriquée de la transaction en cours s'il n'y a pas de transaction actuellement, cette valeur est équivalente à
; TransationDefinition .PROPAGETION_REQUIRED

Transaction déclarative

Utiliser

Regardez maintenant dans Springboot, si vous utilisez une transaction déclarative :

@Transactional
public void save(Object ob){

}

Juste sur la méthode Ajout la méthode d'annotation @Transactional peut être gérée par transactions.

Code source

Regardez le code source de l'annotation Transactional :

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Transactional {

@AliasFor("transactionManager")
String value() default "";


@AliasFor("value")
String transactionManager() default "";

Propagation propagation() default Propagation.REQUIRED;

Isolation isolation() default Isolation.DEFAULT;

int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;


boolean readOnly() default false;

Class<? extends Throwable>[] rollbackFor() default {};


String[] rollbackForClassName() default {};

Class<? extends Throwable>[] noRollbackFor() default {};


String[] noRollbackForClassName() default {};

}

Valeur par défaut

readOnly : Si elle est uniquement en lecture seule . La lecture et l'écriture sont possibles par défaut

timeout : délai d'expiration de la transaction, il n'y a pas de délai d'attente par défaut

isolation : Le niveau d'isolement par défaut de la transaction : TransactionDefinition.ISOLATION_DEFAULT (voir niveau d'isolement ci-dessus)

propagation : attribut de propagation de transaction par défaut : TransactionDefinition.PROPAGATION_REQUIRED

Notes

• Les annotations ne doivent être appliquées qu'aux méthodes publiques

• Problème d'auto-appel : s'il n'y a pas de méthode annotée dans la classe et appelle une méthode annotée, alors lorsqu'une méthode non annotée est appelée en externe, la méthode annotée ne générera pas de transaction

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!