Spring - Gestion des transactions

Une transaction de base de données est une séquence d'actions qui sont traitées comme une seule unité de travail. Ces actions doivent soit se terminer entièrement, soit ne pas avoir d'effet du tout. La gestion des transactions est une partie importante de l'application d'entreprise orientée SGBDR pour garantir l'intégrité et la cohérence des données. Le concept de transactions peut être décrit avec les quatre propriétés clés suivantes décrites commeACID -

• Atomicity - Une transaction doit être traitée comme une seule unité d'opération, ce qui signifie que la séquence entière des opérations est réussie ou non.

• Consistency - Cela représente la cohérence de l'intégrité référentielle de la base de données, des clés primaires uniques dans les tables, etc.

• Isolation- Il peut y avoir plusieurs traitements de transactions avec le même ensemble de données en même temps. Chaque transaction doit être isolée des autres pour éviter la corruption des données.

• Durability - Une fois qu'une transaction est terminée, les résultats de cette transaction doivent être rendus permanents et ne peuvent pas être effacés de la base de données en raison d'une défaillance du système.

Un véritable système de base de données SGBDR garantira les quatre propriétés pour chaque transaction. La vue simpliste d'une transaction émise vers la base de données à l'aide de SQL est la suivante -

• Commencez la transaction à l'aide de la commande begin transaction .

• Effectuez diverses opérations de suppression, de mise à jour ou d'insertion à l'aide de requêtes SQL.

• Si toutes les opérations réussissent, effectuez la validation, sinon annulez toutes les opérations.

Spring Framework fournit une couche abstraite au-dessus des différentes API de gestion des transactions sous-jacentes. Le support des transactions de Spring vise à fournir une alternative aux transactions EJB en ajoutant des capacités de transaction aux POJO. Spring prend en charge la gestion des transactions programmatiques et déclaratives. Les EJB nécessitent un serveur d'applications, mais la gestion des transactions Spring peut être mise en œuvre sans avoir besoin d'un serveur d'applications.

Transactions locales et internationales

Les transactions locales sont spécifiques à une seule ressource transactionnelle comme une connexion JDBC, tandis que les transactions globales peuvent couvrir plusieurs ressources transactionnelles comme la transaction dans un système distribué.

La gestion des transactions locales peut être utile dans un environnement informatique centralisé où les composants d'application et les ressources sont situés sur un seul site, et la gestion des transactions n'implique qu'un gestionnaire de données local s'exécutant sur une seule machine. Les transactions locales sont plus faciles à mettre en œuvre.

La gestion globale des transactions est requise dans un environnement informatique distribué où toutes les ressources sont réparties sur plusieurs systèmes. Dans un tel cas, la gestion des transactions doit être effectuée aux niveaux local et mondial. Une transaction distribuée ou globale est exécutée sur plusieurs systèmes et son exécution nécessite une coordination entre le système global de gestion des transactions et tous les gestionnaires de données locaux de tous les systèmes impliqués.

Programmatique vs déclaratif

Spring prend en charge deux types de gestion des transactions -

• Gestion des transactions par programmation - Cela signifie que vous devez gérer la transaction à l'aide de la programmation. Cela vous donne une flexibilité extrême, mais c'est difficile à maintenir.

• Gestion des transactions déclaratives - Cela signifie que vous séparez la gestion des transactions du code métier. Vous n'utilisez que des annotations ou une configuration XML pour gérer les transactions.

La gestion déclarative des transactions est préférable à la gestion des transactions programmatiques, bien qu'elle soit moins flexible que la gestion des transactions programmatiques, qui vous permet de contrôler les transactions via votre code. Mais comme une sorte de préoccupation transversale, la gestion déclarative des transactions peut être modularisée avec l'approche AOP. Spring prend en charge la gestion déclarative des transactions via le framework Spring AOP.

Abstractions de transaction de printemps

La clé de l'abstraction de la transaction Spring est définie par l' interface org.springframework.transaction.PlatformTransactionManager , qui se présente comme suit -

public interface PlatformTransactionManager {
   TransactionStatus getTransaction(TransactionDefinition definition);
   throws TransactionException;
   
   void commit(TransactionStatus status) throws TransactionException;
   void rollback(TransactionStatus status) throws TransactionException;
}

Sr. Non	Méthode et description
1	TransactionStatus getTransaction(TransactionDefinition definition) Cette méthode renvoie une transaction actuellement active ou en crée une nouvelle, selon le comportement de propagation spécifié.
2	void commit(TransactionStatus status) Cette méthode valide la transaction donnée, en ce qui concerne son statut.
3	void rollback(TransactionStatus status) Cette méthode effectue une annulation de la transaction donnée.

Le TransactionDefinition est l'interface de base de support de transaction au printemps et elle est définie comme suit : -

public interface TransactionDefinition {
   int getPropagationBehavior();
   int getIsolationLevel();
   String getName();
   int getTimeout();
   boolean isReadOnly();
}

Sr. Non	Méthode et description
1	int getPropagationBehavior() Cette méthode renvoie le comportement de propagation. Spring offre toutes les options de propagation de transaction familières d'EJB CMT.
2	int getIsolationLevel() Cette méthode renvoie la mesure dans laquelle cette transaction est isolée du travail d'autres transactions.
3	String getName() Cette méthode renvoie le nom de cette transaction.
4	int getTimeout() Cette méthode renvoie le temps en secondes pendant lequel la transaction doit se terminer.
5	boolean isReadOnly() Cette méthode renvoie si la transaction est en lecture seule.

Voici les valeurs possibles pour le niveau d'isolement -

Sr. Non	Isolation et description
1	TransactionDefinition.ISOLATION_DEFAULT Il s'agit du niveau d'isolement par défaut.
2	TransactionDefinition.ISOLATION_READ_COMMITTED Indique que les lectures incorrectes sont empêchées; des lectures non répétables et des lectures fantômes peuvent se produire.
3	TransactionDefinition.ISOLATION_READ_UNCOMMITTED Indique que des lectures incorrectes, des lectures non répétables et des lectures fantômes peuvent se produire.
4	TransactionDefinition.ISOLATION_REPEATABLE_READ Indique que les lectures incorrectes et les lectures non répétables sont empêchées; des lectures fantômes peuvent se produire.
5	TransactionDefinition.ISOLATION_SERIALIZABLE Indique que les lectures incorrectes, les lectures non répétables et les lectures fantômes sont empêchées.

Voici les valeurs possibles pour les types de propagation -

N ° Sr.	Propagation et description
1	TransactionDefinition.PROPAGATION_MANDATORY Prend en charge une transaction en cours; lève une exception si aucune transaction en cours n'existe.
2	TransactionDefinition.PROPAGATION_NESTED S'exécute dans une transaction imbriquée si une transaction en cours existe.
3	TransactionDefinition.PROPAGATION_NEVER Ne prend pas en charge une transaction en cours; lève une exception si une transaction en cours existe.
4	TransactionDefinition.PROPAGATION_NOT_SUPPORTED Ne prend pas en charge une transaction en cours; plutôt toujours exécuter de manière non transactionnelle.
5	TransactionDefinition.PROPAGATION_REQUIRED Prend en charge une transaction en cours; en crée un nouveau s'il n'en existe pas.
6	TransactionDefinition.PROPAGATION_REQUIRES_NEW Crée une nouvelle transaction, suspendant la transaction en cours s'il en existe une.
sept	TransactionDefinition.PROPAGATION_SUPPORTS Prend en charge une transaction en cours; s'exécute de manière non transactionnelle s'il n'en existe pas.
8	TransactionDefinition.TIMEOUT_DEFAULT Utilise le délai d'expiration par défaut du système de transaction sous-jacent, ou aucun si les délais d'expiration ne sont pas pris en charge.

L' interface TransactionStatus fournit un moyen simple pour le code transactionnel de contrôler l'exécution de la transaction et d'interroger le statut de la transaction.

public interface TransactionStatus extends SavepointManager {
   boolean isNewTransaction();
   boolean hasSavepoint();
   void setRollbackOnly();
   boolean isRollbackOnly();
   boolean isCompleted();
}

N ° Sr.	Méthode et description
1	boolean hasSavepoint() Cette méthode renvoie si cette transaction porte en interne un point de sauvegarde, c'est-à-dire qu'elle a été créée en tant que transaction imbriquée basée sur un point de sauvegarde.
2	boolean isCompleted() Cette méthode renvoie si cette transaction est terminée, c'est-à-dire si elle a déjà été validée ou annulée.
3	boolean isNewTransaction() Cette méthode renvoie true au cas où la transaction actuelle serait nouvelle.
4	boolean isRollbackOnly() Cette méthode renvoie si la transaction a été marquée comme annulation uniquement.
5	void setRollbackOnly() Cette méthode définit la transaction en tant que restauration uniquement.