Que signifie une transaction Java ?

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 des transactions fait passer la base de données d'un état à un autre.

1. Les affaires 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/IEC. 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 produit.

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 fournie à aucune autre transaction, c'est-à-dire qu'avant que la transaction ne soit correctement validée, ses résultats possibles ne doivent être affichés pour 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. ​

Exécutez une application ou un script SQL intégré et la transaction démarrera automatiquement lorsque l'instruction SQL exécutable sera exécutée pour la première fois (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 lorsque le système de base de données termine l'exécution d'un SQL After. le relevé, la transaction est automatiquement validée. Mode de validation manuelle : la limite de début et la limite de fin de la transaction doivent être explicitement spécifiées par le client de la base de données.

Remarque : Il existe trois types de tables de base de données dans MySQL : 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é, il entraînera divers problèmes de concurrence, ces problèmes de concurrence peuvent être résumés dans les catégories suivantes :

Le premier type de mise à jour perdue : lorsqu'une transaction est révoquée, les données de mise à jour soumises par d'autres transactions sont é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 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, qui peut être appliqué dans l'application. Un verrouillage pessimiste ou optimiste est utilisé dans le programme pour éviter de tels problèmes. 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 : pendant l'exécution, une transaction peut voir les enregistrements nouvellement insérés qui ont été soumis par d'autres transactions, mais elle ne peut pas voir les mises à jour des enregistrements existants par d'autres transactions. Lecture validée (lecture des données validées) : pendant l'exécution d'une transaction, vous pouvez voir les enregistrements nouvellement insérés qui ont été validés par d'autres transactions, ainsi que les mises à jour des enregistrements existants qui ont été validés par d'autres transactions. données non validées) ) : pendant 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 les mises à jour des enregistrements existants qui n'ont pas été validés par d'autres transactions.

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 simultanéité 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 adopte le niveau d'isolement de lecture validée, cela entraînera une lecture non répétable et le deuxième type de problèmes de concurrence de mise à jour perdue. Vous pouvez utiliser le verrouillage pessimiste ou le verrouillage optimiste 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 en cours exploite la ressource de données, aucune autre transaction n'accédera à la ressource de données en même temps, elle repose donc entièrement sur le niveau d'isolation de la base de données pour automatiquement gérer le travail de serrure. 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 ... pour la mise à jour, utilisez get dans Hibernate, chargez tel que session.get(Account.class,new Long(1),LockMode,UPGRADE)

B Ajouter dans la table de base de données A. Champ LOCK indiquant l'état de l'enregistrement. Lorsque sa valeur est "Y", cela signifie que l'enregistrement a été verrouillé par une transaction. S'il est "N", cela signifie que l'enregistrement est dans un état 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 d'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 les applications, vous pouvez utiliser la fonction de contrôle de version fournie par Hibernate pour implémenter le verrouillage optimiste. L'élément et dans le fichier de mappage OR ont tous deux des fonctions de contrôle de version. pour 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!