Une introduction détaillée aux transactions de base Java-javaDidacticiel-php.cn

Cet article présente principalement des informations pertinentes sur l'introduction détaillée des transactions de base Java. Les amis qui en ont besoin peuvent se référer à

Explication détaillée des transactions Java

1 , Qu'est-ce qu'une transaction

Une transaction est une séquence d'opérations pour accéder à la base de données. Le système d'application de base de données complète l'accès à la base de données via des ensembles de transactions. L'exécution correcte d'une transaction provoque la transition de la base de données d'un

état à un autre.

Les transactions doivent être conformes aux principes ACID établis par l'ISO/IEC. ACID est l'abréviation d'atomicité, de cohérence, d'isolement et de durabilité. Les transactions doivent être conformes aux principes ACID établis par l'ISO/CEI. ACID est l'abréviation d'atomicité, de cohérence, d'isolation et de durabilité.

Atomique. C'est-à-dire l'indivisibilité, soit toutes les transactions sont exécutées, soit aucune n'est exécutée. Si toutes les sous-transactions de la transaction sont soumises avec succès, toutes les opérations de base de données sont soumises et l'état de la base de données est converti si une sous-transaction échoue, les opérations de base de données des autres sous-transactions sont annulées, c'est-à-dire que la base de données revient à l'état avant l'exécution de la transaction, aucune transition d'état ne se produira.

Cohérence ou cordabilité. L'exécution d'une transaction convertit la base de données d'un état correct à un autre. Isolement. Avant que la transaction ne soit correctement validée, toute modification apportée aux données par la transaction ne peut être transmise à aucune autre transaction, c'est-à-dire que jusqu'à ce que la transaction soit correctement validée, ses résultats possibles ne doivent être affichés dans aucune autre transaction.

Persistance. Une fois qu'une transaction est soumise correctement, ses résultats seront enregistrés de manière permanente dans la base de données. Même s'il y a d'autres échecs après la soumission de la transaction, les résultats du traitement de la transaction seront enregistrés.

En exécutant une application ou un script SQL intégré, la transaction démarrera automatiquement la première fois que l'instruction SQL exécutable sera exécutée (après l'établissement de la connexion à la base de données ou après la fin de la transaction existante). Après le démarrage d'une transaction, celle-ci doit être explicitement terminée par l'utilisateur ou l'application qui a démarré la transaction, à moins qu'un processus appelé validation automatique ne soit utilisé (auquel cas chaque instruction SQL émise est visualisée. L'exécution d'une seule transaction est implicitement validée dès qu'elle est exécuté).

Dans la plupart des cas, une transaction est terminée en exécutant une instruction COMMIT ou ROLLBACK. Lorsque l'instruction COMMIT est exécutée, toutes les modifications apportées à la base de données depuis le démarrage de la transaction deviennent permanentes, c'est-à-dire qu'elles sont écrites sur le disque. Lorsque l'instruction ROLLBACK est exécutée, toutes les modifications apportées à la base de données depuis le début de la transaction sont annulées et la base de données revient à l'état dans lequel elle se trouvait avant le début de la transaction. Dans les deux cas, la base de données est garantie de revenir à un état cohérent une fois la transaction terminée.

Il est important de noter que bien que les transactions assurent la cohérence générale de la base de données en garantissant que les modifications apportées aux données ne deviennent permanentes qu'une fois la transaction validée avec succès, cela nécessite toujours que l'utilisateur ou l'application garantisse la séquence des opérations SQL effectuées dans chaque transaction aboutit toujours à une base de données cohérente.

2. Le système de base de données prend en charge deux modes de transaction :

Mode de validation automatique : chaque instruction SQL est une transaction indépendante après la base de données. Le système exécute une instruction SQL, il soumettra automatiquement la transaction.

Mode de validation manuelle : la limite de début et la limite de fin de la transaction doivent être spécifiées explicitement par le programme client de la base de données.

Remarque : Les tables de base de données dans

MySQL sont divisées en 3 types : INNODB, BDB et MyISAM, parmi lesquels MyISAM ne prend pas en charge les transactions de base de données. L'instruction create table dans MySQL est par défaut le type MyISAM.

3. Pour plusieurs transactions exécutées en même temps, lorsque ces transactions accèdent aux mêmes données dans la base de données, si le mécanisme d'isolation nécessaire n'est pas adopté, divers problèmes de concurrence se produiront. Ces problèmes de concurrence peuvent être résumés comme suit. suit Plusieurs catégories :

Le premier type de perte
Mise à jour : Lorsqu'une transaction est révoquée, les données mises à jour soumises par d'autres transactions seront écrasées.
Lecture sale : une transaction lit les données mises à jour soumises par une autre transaction.
Lecture factice : une transaction lit les données nouvellement insérées qui ont été soumises par une autre transaction.
Lecture non répétable : une transaction lit les données mises à jour qui ont été soumises par une autre transaction.
Le deuxième type de mise à jour perdue : il s'agit d'un cas particulier de lecture non répétable, où une transaction écrase les données mises à jour soumises par une autre transaction.

4. Niveau d'isolement

Lorsque le système de base de données adopte le niveau d'isolement read Commited, cela conduira au deuxième type de lecture non répétable Le problème de concurrence des mises à jour perdues peut être évité en utilisant le verrouillage pessimiste ou le verrouillage optimiste dans l'application. Du point de vue des applications, les verrous peuvent être divisés dans les catégories suivantes :

Sérialisable : Une transaction ne peut pas voir les mises à jour apportées à la base de données par d'autres transactions lors de l'exécution.
Lecture répétable : lors de l'exécution d'une transaction, vous pouvez voir les enregistrements nouvellement insérés qui ont été soumis par d'autres transactions, mais vous ne pouvez pas voir les modifications apportées aux enregistrements existants par d'autres transactions renouvelées.
Lecture validée (lire les données validées) : lors de l'exécution d'une transaction, vous pouvez voir les enregistrements nouvellement insérés qui ont été validés par d'autres transactions, et vous pouvez également voir les paires qui ont été validés par d'autres transactions. Mise à jour des enregistrements existants
Lire non validé (lire les données non validées) : Lors de l'exécution, une transaction peut copier les enregistrements nouvellement insérés qui n'ont pas été validés par d'autres transactions, et peut voir d'autres transactions. Il n'y a aucune mise à jour validée pour les enregistrements existants.

Plus le niveau d'isolement est élevé, plus les données peuvent être garanties complètes et cohérentes, mais plus l'impact sur les performances de concurrence est grand. Pour la plupart des applications, vous pouvez donner la priorité à la définition du niveau d'isolement du système de base de données sur Read Commited, ce qui peut éviter les lectures sales et offrir de meilleures performances de concurrence. Bien que cela entraîne des problèmes de concurrence tels que des lectures non répétables, des lectures virtuelles et des mises à jour perdues de deuxième type, dans des situations individuelles où de tels problèmes peuvent survenir, ils peuvent être contrôlés par l'application à l'aide de verrous pessimistes ou de verrous optimistes.

Lorsque le système de base de données utilise le niveau d'isolement de lecture validée, cela entraînera des lectures non répétables et le deuxième type de problèmes de concurrence de mise à jour perdue. Vous pouvez utiliser des verrous pessimistes ou des verrous optimistes dans l'application pour éviter de tels problèmes. . Du point de vue de l'application, les verrous peuvent être divisés dans les catégories suivantes :

　A. Verrouillage pessimiste : fait référence au verrouillage des ressources de données affichées dans l'application. Bien qu'il évite les problèmes de concurrence tels que la perte de mises à jour et les lectures non répétables, il affecte les performances de concurrence et doit être utilisé avec prudence.

　B. Verrouillage optimiste : Le verrouillage optimiste suppose que lorsque la transaction actuelle exploite la ressource de données, aucune autre transaction n'accédera à la ressource de données en même temps, donc il s'appuie entièrement sur l'isolation des niveaux de base de données pour gérer automatiquement les verrous. Les applications utilisent le contrôle de version pour éviter d'éventuels problèmes de concurrence.

5. Il existe deux manières de mettre en œuvre le verrouillage pessimiste.

A. Afficher dans le programme d'application et spécifier l'utilisation exclusive du système de base de données pour verrouiller les ressources de données. Instruction SQL : sélectionnez... pourupdate, utilisez get en veille prolongée, lors du chargement, comme session.get(Account .class,new Long(1),LockMode,UPGRADE)

　B. Ajoutez un champ LOCK indiquant l'état de l'enregistrement dans la table de la base de données. Lorsqu'il prend la valeur "Y", Indique que l'enregistrement a été verrouillé par une transaction. S'il vaut "N", cela indique que l'enregistrement est inactif et que la transaction peut y accéder. Ceci peut être réalisé en ajoutant un champ de balise de verrouillage.

Utilisez le contrôle de version Hibernate pour implémenter le verrouillage optimiste

Le verrouillage optimiste est un mécanisme fourni par le programme. Ce mécanisme peut non seulement garantir que plusieurs transactions accèdent aux données simultanément, mais également empêcher la disparition de la deuxième classe. problème de mise à jour.

Dans l'application, vous pouvez utiliser la fonction de contrôle de version fournie par Hibernate pour afficher le verrouillage optimiste. L'élément et <timestamp> fonction de contrôle de version, il est généralement recommandé d'utiliser

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!