Transaction Spring (JDBC) pour les transactions en Java

Caractéristiques des transactions :

1) Atomicité : Une transaction est une unité de travail logique de la base de données, et elle doit être une unité de travail atomique Pour ses modifications de données, soit toutes sont exécutées. ou aucun d'entre eux n'est exécuté.

2) Cohérence : Lorsqu'une transaction est terminée, toutes les données doivent être cohérentes. Dans la base de données concernée, toutes les règles doivent être appliquées aux modifications des transactions afin de maintenir l'intégrité de toutes les données.

3) Isolement : L'exécution d'une transaction ne peut pas être affectée par d'autres transactions.

4) Durabilité : Une fois qu'une transaction est soumise, le fonctionnement de la transaction est stocké en permanence dans la base de données. Même si vous effectuez une opération de restauration à ce moment-là, les modifications ne seront pas annulées.

Transaction : il s'agit d'une unité de contrôle de concurrence et d'une séquence d'opérations définie par l'utilisateur. Soit toutes ces opérations sont effectuées, soit aucune d’entre elles n’est effectuée, et elles constituent une unité de travail intégrale. Grâce aux transactions, SQL Server peut lier un ensemble d’opérations logiquement liées afin que le serveur préserve l’intégrité des données. Une transaction commence généralement par le début de la transaction et se termine par une validation ou une annulation. Commint signifie soumission, c'est-à-dire toutes les opérations de validation d'une transaction. Plus précisément, toutes les mises à jour des données de la transaction sont réécrites dans la base de données physique sur le disque et la transaction se termine normalement. Rollback signifie restauration, c'est-à-dire qu'une sorte d'échec se produit pendant l'exécution de la transaction et que la transaction ne peut pas continuer. Le système annule toutes les opérations terminées sur la base de données dans la transaction et revient à l'état dans lequel la transaction a commencé.

Transactions à validation automatique : chaque relevé individuel est une transaction. Il y a un commit implicite après chaque instruction. (Par défaut)

Transaction explicite : commence par le début de l'affichage de la transaction et se termine par une validation ou une annulation.

Transaction implicite : lorsque la connexion fonctionne en mode transaction implicite, l'instance du moteur de base de données SQL Server démarre automatiquement une nouvelle transaction après avoir validé ou annulé la transaction en cours. Il n'est pas nécessaire de décrire le début des choses, il suffit de valider ou d'annuler chaque transaction. Mais chaque transaction se termine toujours explicitement par une validation ou une annulation. Une fois que la connexion a défini le mode de transaction implicite sur ouvert, une transaction implicite sera automatiquement démarrée lorsque l'instance du moteur de base de données exécute l'une des instructions suivantes pour la première fois : alter table, insert, create, open, delete, revoke, drop, select. , fetch, troncate table, grant, update transaction resteront valides jusqu'à ce qu'une instruction de validation ou d'annulation soit émise. Une fois la première transaction validée ou annulée, l'instance du moteur de base de données démarre automatiquement une nouvelle transaction la prochaine fois que la connexion exécute l'une des instructions ci-dessus. Cette instance continuera à générer des chaînes de transactions implicites jusqu'à ce que le mode de transaction implicite soit désactivé.

Mécanisme de transaction Java JDBC

Tout d'abord, examinons les problèmes majeurs que les opérations JDBC existantes nous causeront. Par exemple, il y a une entreprise : quand nous. modifier a Après avoir interrogé les informations, il s'avère qu'il s'agit d'une entreprise simple et très facile à mettre en œuvre. Cependant, lorsque cette entreprise est placée sur une plate-forme multithread à haute concurrence, des problèmes surviennent naturellement, par exemple. exécuter une modification Enfin, avant d'exécuter la requête, un thread a également exécuté l'instruction de modification. Si nous exécutons à nouveau la requête, les informations que nous voyons peuvent être différentes de celles que nous avons modifiées. Afin de résoudre ce problème, nous devons introduire la transaction JDBC. Mécanisme. En fait, le code La mise en œuvre est très simple. Voici un exemple de mise en œuvre de principe pour votre référence :

private Connection conn = null;  
private PreparedStatement ps = null;  
 
try {  
    conn.setAutoCommit(false);  //将自动提交设置为false  
              
    ps.executeUpdate("修改SQL"); //执行修改操作  
    ps.executeQuery("查询SQL");  //执行查询操作                 
    conn.commit();      //当两个操作成功后手动提交  
              
} catch (Exception e) {  
    conn.rollback();    //一旦其中一个操作出错都将回滚，使两个操作都不成功  
    e.printStackTrace();  
}

Théories liées aux transactions
1. Transaction)
Atomic Atomic Soit toutes les modifications des données sont effectuées, soit aucune n'est effectuée.
Cohérent (Cohérent) L'état des données reste cohérent avant et après l'exécution de la transaction.
Isolé Le traitement d'une transaction ne peut pas affecter le traitement d'une autre transaction.
Le traitement durable des transactions se termine et ses effets sont conservés dans la base de données.

2. Problèmes possibles causés par le traitement simultané des transactions
Lecture sale (lecture sale) Une transaction lit des données qui n'ont pas été soumises par une autre transaction,
Lecture non répétable (lecture non répétable) A L'opération d'une transaction amène une autre transaction à lire des données différentes deux fois avant et après
Lecture fantôme (lecture fantôme) L'opération d'une transaction amène une autre transaction à lire des quantités de données différentes deux fois avant et après la requête.
Exemple :
Lorsque les transactions A et B sont exécutées simultanément,
après la mise à jour de la transaction A, la transaction B choisit de lire les données non validées de A. À ce moment, la transaction A est annulée, puis les données lues par B correspond à des données « sales » non valides.
Lorsque la transaction B choisit de lire les données, une opération de mise à jour de la transaction modifie les données sélectionnées par la transaction B. À ce moment, la transaction B lit à nouveau les données et constate que les données des deux fois précédentes sont différentes.
Une fois que la transaction B a choisi de lire les données, la transaction A insère ou supprime un enregistrement qui satisfait aux conditions de sélection de la transaction A. À ce stade, la transaction B sélectionne à nouveau et constate qu'un enregistrement qui n'existait pas la dernière fois a été interrogé ( "fantôme"). Ou un certain enregistrement de la fois précédente est manquant.

Prise en charge des transactions par JDBC
La prise en charge des transactions par JDBC se reflète dans trois aspects :
1 Mode de validation automatique (Mode de validation automatique)
La connexion fournit un attribut de validation automatique pour spécifier une transaction Quand. ça se termine.
a. Lorsque la validation automatique est vraie, lorsque l'exécution de chaque opération SQL indépendante est terminée, la transaction est automatiquement soumise immédiatement, ce qui signifie que chaque opération SQL est une transaction.
Quand une opération SQL indépendante est terminée ? La spécification JDBC stipule ceci :
Pour le langage d'opération de données (DML, tel que l'insertion, la mise à jour, la suppression) et le langage de définition de données (tel que la création, la suppression), instruction une fois exécuté, il est réputé terminé.
Pour une instruction select, l'exécution est considérée comme terminée lorsque l'objet ResultSet qui lui est associé est fermé.
Pour les procédures stockées ou autres instructions qui renvoient plusieurs résultats, lorsque tous les objets ResultSet qui y sont associés sont fermés, tout le nombre de mises à jour (le nombre de lignes affectées par les opérations de mise à jour, de suppression et autres opérations d'instruction) et les paramètres de sortie (paramètres de sortie du procédure stockée) ) ont été obtenus, l'exécution est réputée terminée.
b. Lorsque la validation automatique est fausse, chaque transaction doit appeler explicitement la méthode de validation pour valider, ou appeler explicitement la méthode de restauration pour revenir en arrière. la validation automatique est par défaut true.
JDBC fournit 5 niveaux d'isolation de transactions différents, qui sont définis dans Connection.

2. Niveaux d'isolement des transactions
JDBC définit cinq niveaux d'isolement des transactions :
TRANSACTION_NONE Le pilote JDBC ne prend pas en charge les transactions
TRANSACTION_READ_UNCOMMITTED autorise les lectures sales, les lectures non répétables et les lectures fantômes.
TRANSACTION_READ_COMMITTED interdit les lectures sales, mais autorise les lectures non répétables et les lectures fantômes.
TRANSACTION_REPEATABLE_READ interdit les lectures sales et non répétables, ainsi que les lectures fantômes à exécution unique.
TRANSACTION_SERIALIZABLE interdit les lectures sales, les lectures non répétables et les lectures fantômes.

3. SavePoint (SavePoint)
JDBC définit l'interface SavePoint pour fournir un mécanisme de contrôle des transactions plus précis. Lorsqu'un point de sauvegarde est défini, vous pouvez revenir à l'état du point de sauvegarde au lieu d'annuler l'intégralité de la transaction.
Les méthodes setSavepoint et releaseSavepoint de l'interface Connection peuvent définir et libérer des points de sauvegarde.

Bien que la spécification JDBC définisse les comportements de prise en charge ci-dessus pour les transactions, chaque pilote JDBC et fabricant de base de données peut avoir différents niveaux de prise en charge pour les transactions. Si vous le définissez arbitrairement dans le programme, vous risquez de ne pas obtenir l'effet souhaité. À cette fin, JDBC fournit l'interface DatabaseMetaData, qui fournit une série de méthodes pour obtenir la prise en charge des fonctionnalités JDBC. Par exemple, la prise en charge des niveaux d'isolement des transactions peut être déterminée via la méthode DatabaseMetaData.supportsTransactionIsolationLevel, et la prise en charge des points de sauvegarde peut être déterminée via la méthode DatabaseMetaData.supportsSavepoints.

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!