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.
(É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...^ _ ^)
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.
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 : 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)
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.
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 _COMMITTEDUne 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 _READUne 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 _SERIALIZBLEToutes 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.REQUIREDSi 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.
Cela signifie créer une nouvelle transaction, qui n'a rien à voir avec la transaction originale.
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.
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.
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.
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.
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
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.
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 {}; }
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
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!