Annotation de transaction SpringBoot @Transactional

SpringBoot fournit des opérations de transaction très pratiques. Vous pouvez implémenter l'annulation de transaction via des annotations, ce qui est très pratique et rapide. Parlons de la façon d'effectuer des opérations de transaction.

1. Description de l'entreprise

Au printemps, il existe deux façons d'implémenter des transactions, à savoir la gestion des transactions par programme et la gestion des transactions déclaratives. 
Gestion des transactions par programme: la gestion des transactions par programme utilise TransactionTemplate ou utilise directement le PlatformTransactionManager sous-jacent. Pour la gestion des transactions par programme, Spring recommande d'utiliser TransactionTemplate. 
Gestion déclarative des transactions: construite sur AOP. Son essence est d'intercepter avant et après la méthode, puis de créer ou d'ajouter une transaction avant le démarrage de la méthode cible, et de soumettre ou d'annuler la transaction en fonction de l'exécution après l'exécution de la méthode cible. 
La gestion déclarative des transactions ne nécessite pas de code d'intrusion et les opérations de transaction peuvent être effectuées via @Transactional, qui est plus rapide et plus simple. Utilisation recommandée

2. Comment utiliser

L'utilisation des transactions dans Mybatis est très simple: il suffit d'ajouter l'annotation @Transactional à la fonction sans aucune configuration. Jetons un coup d'œil à l'exemple d'ajout de transactions dans la couche contrôleur:

@Autowired
OrderServiceorderService;   //order操作的Service层

@ApiOperation(value = "增加OrderCustomer")
@RequestMapping(value = "", method = RequestMethod.POST)
@ResponseBody
@Transactional
public JsonBean<Order> insertOrder(@RequestParam(value = "order") String order) {
    try {
        //创建订单
        Order order = orderService.insert(user.getId(),is_company,fk_want_company_id);
        return new JsonBean(SUCCESS, orderCustomer);
    } 
    catch (ErrorCodeException e)
    {
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
        return new JsonBean(e.getErrorCode());
    }
}
wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw ==


@Transactional peut agir sur les interfaces, les méthodes d'interface, les classes et les méthodes de classe. Lorsqu'elles sont utilisées comme classe, toutes les méthodes publiques de la classe auront l'attribut transaction de ce type. En même temps, nous pouvons également utiliser cette annotation au niveau de la méthode pour remplacer la définition au niveau de la classe. Par conséquent, il peut être utilisé dans la couche Service et la couche Controller. L'exemple ci-dessus est implémenté dans la couche Controller. Nous simulons une interface de soumission de commande, où JsonBean est la classe de base pour le retour uniforme des codes d'erreur et ErrorCodeException est une exception.

Grâce à @Transactional, des opérations de transaction sont réalisées.
L'AOP de Spring, la gestion déclarative des transactions, revient par défaut à la restauration pour les exceptions non vérifiées. Autrement dit, par défaut, l'exception RuntimeException () ou ses sous-classes sont annulées; l'exception vérifiée, c'est-à-dire que l'exception peut être interceptée par try {} et ne sera pas annulée. Par conséquent, pour notre exception personnalisée, nous définissons par le biais de rollbackFor, et cela sera fait séparément plus tard. Disons que
si nous devons attraper l'exception, en même temps, rollback par TransactionAspectSupport.currentTransactionStatus () setRollbackOnly (); rollback manuel.
Utilisez Object savePoint = TransactionAspectSupport.currentTransactionStatus (). CreateSavepoint (); pour 
définir le point de restauration, utilisez TransactionAspectSupport.currentTransactionStatus (). RollbackToSavepoint (savePoint); pour revenir à savePoint.
3. Configuration commune

Nom du paramètre Description de la fonction
readOnly Cet attribut est utilisé pour définir si la transaction en cours est une transaction en lecture seule, défini sur true pour indiquer la lecture seule, false pour indiquer la lecture-écriture et la valeur par défaut est false. Par exemple: @Transactional (readOnly = true)
rollbackFor Cet attribut est utilisé pour définir le tableau de classes d'exceptions qui doit être annulé. Lorsqu'une exception dans le tableau d'exceptions spécifié est levée dans la méthode, la transaction est annulée. Par exemple: spécifiez une seule classe d'exception: @Transactional (rollbackFor = RuntimeException.class) spécifiez plusieurs classes d'exception: @Transactional (rollbackFor = {RuntimeException.class, Exception.class})
rollbackForClassName Cet attribut est utilisé pour définir la classe d'exception qui a besoin à annuler Le tableau de noms, lorsque l'exception dans le tableau de noms d'exception spécifié est levée dans la méthode, la transaction est annulée. Par exemple: spécifiez un seul nom de classe d'exception @Transactional (rollbackForClassName = ”RuntimeException”) spécifiez plusieurs noms de classe d'exception: @Transactional (rollbackForClassName = {"RuntimeException", "Exception"})
noRollbackFor Cet attribut est utilisé pour définir l'annulation non requise Tableau de classe d'exception, lorsque l'exception dans le tableau d'exceptions spécifié est levée dans la méthode, la transaction ne sera pas annulée. Par exemple: Spécifiez une seule classe d'exception: @Transactional (noRollbackFor = RuntimeException.class) Spécifiez plusieurs classes d'exception: @Transactional (noRollbackFor = {RuntimeException.class, Exception.class})
noRollbackForClassName Cet attribut est utilisé pour définir le tableau des noms de classes d'exceptions qui n'ont pas besoin d'être annulés. Lorsqu'une exception dans le tableau de noms d'exceptions spécifié est levée dans la méthode, la transaction ne sera pas annulée. Par exemple: spécifiez un seul nom de classe d'exception: @Transactional (noRollbackForClassName = "RuntimeException") spécifiez plusieurs noms de classe d'exception: @Transactional (noRollbackForClassName = {"RuntimeException", "Exception"})
propagation Cet attribut est utilisé pour définir le comportement de propagation de la transaction. Par exemple: @Transactional (propagation = Propagation.NOT_SUPPORTED, readOnly = true)
isolation Cette propriété est utilisée pour définir le niveau d'isolation des transactions de la base de données sous-jacente. Le niveau d'isolation des transactions est utilisé pour gérer le cas de plusieurs transactions simultanément. le niveau d'isolement par défaut de la base de données peut être utilisé. Fondamentalement, il n'est pas nécessaire de définir le
délai d'expiration Cet attribut est utilisé pour définir les secondes de délai d'expiration de la transaction, la valeur par défaut est -1, ce qui signifie qu'il n'y a jamais d'expiration de délai
4. Attributs de transaction

Le niveau d' 
isolement du niveau d'isolement des transactions fait référence au degré d'isolement entre plusieurs transactions simultanées. Cinq constantes représentant le niveau d'isolement sont définies dans l'interface TransactionDefinition:

TransactionDefinition.ISOLATION_DEFAULT: il s'agit de la valeur par défaut, ce qui signifie que le niveau d'isolement par défaut de la base de données sous-jacente est utilisé. Pour la plupart des bases de données, cette valeur est généralement TransactionDefinition.ISOLATION_READ_COMMITTED. 
TransactionDefinition.ISOLATION_READ_UNCOMMITTED: ce niveau d'isolement signifie qu'une transaction peut lire des données modifiées par une autre transaction mais n'a pas encore été validée. Ce niveau ne peut pas empêcher les lectures incorrectes, les lectures non répétables et les lectures fantômes, ce niveau d'isolement est donc rarement utilisé. Par exemple, PostgreSQL n'a pas réellement ce niveau. 
TransactionDefinition.ISOLATION_READ_COMMITTED: ce niveau d'isolement signifie qu'une transaction ne peut lire que les données qui ont été validées par une autre transaction. Ce niveau peut empêcher les lectures incorrectes, qui est également la valeur recommandée dans la plupart des cas. 
TransactionDefinition.ISOLATION_REPEATABLE_READ: ce niveau d'isolement signifie qu'une transaction peut exécuter une requête plusieurs fois pendant tout le processus, et les enregistrements renvoyés à chaque fois sont identiques. Ce niveau peut empêcher les lectures incorrectes et les lectures non répétables. 
TransactionDefinition.ISOLATION_SERIALIZABLE: Toutes les transactions sont exécutées une par une, de sorte qu'il n'y a pas d'interférence entre les transactions, c'est-à-dire que ce niveau peut empêcher les lectures sales, les lectures non répétables et les lectures fantômes. Mais cela affectera gravement les performances du programme. Normalement, ce niveau n'est pas utilisé non plus.

Comportement de propagation de transaction Le 
soi-disant comportement de propagation de transaction signifie que si un contexte de transaction existe déjà avant de démarrer la transaction en cours, il existe plusieurs options pour spécifier le comportement d'exécution d'une méthode transactionnelle. Les constantes suivantes représentant le comportement de propagation sont incluses dans la définition TransactionDefinition:

TransactionDefinition.PROPAGATION_REQUIRED: S'il y a une transaction actuellement, rejoignez la transaction; s'il n'y a pas de transaction actuellement, créez une nouvelle transaction. C'est la valeur par défaut. 
TransactionDefinition.PROPAGATION_REQUIRES_NEW: Créez une nouvelle transaction, s'il y a une transaction actuellement, puis suspendez la transaction en cours. 
TransactionDefinition.PROPAGATION_SUPPORTS: s'il y a actuellement une transaction, rejoignez la transaction; s'il n'y a pas de transaction en cours, continuez à s'exécuter de manière non transactionnelle. 
TransactionDefinition.PROPAGATION_NOT_SUPPORTED: exécution en mode non transactionnel. S'il y a une transaction actuellement, la transaction en cours est suspendue. 
TransactionDefinition.PROPAGATION_NEVER: exécution en mode non transactionnel. S'il y a une transaction actuellement, une exception sera levée. 
TransactionDefinition.PROPAGATION_MANDATORY: S'il y a une transaction actuellement, rejoignez la transaction; s'il n'y a pas de transaction actuellement, une exception sera levée. 
TransactionDefinition.PROPAGATION_NESTED: s'il existe actuellement une transaction, créez une transaction à exécuter en tant que transaction imbriquée de la transaction en cours; s'il n'y a pas de transaction en cours, la valeur est équivalente à TransactionDefinition.PROPAGATION_REQUIRED.

Délai d'expiration du
mouvement Ce que l'  on appelle le délai d'expiration de la transaction fait référence à la durée maximale pendant laquelle une transaction est autorisée à s'exécuter. Si le délai est dépassé mais que la transaction n'est pas terminée, la transaction est automatiquement annulée. La valeur int est utilisée pour représenter le délai d'expiration dans TransactionDefinition et l'unité est en secondes. 
Le paramètre par défaut est la valeur du délai d'expiration du système de transactions sous-jacent. Si le système de transactions de la base de données sous-jacent ne définit pas de valeur de délai d'expiration, alors il est nul et il n'y a pas de limite de délai.

Propriété en 
lecture seule de transaction La transaction en lecture seule est utilisée lorsque le code client est en lecture seule mais ne modifie pas les données. La transaction en lecture seule est utilisée pour l'optimisation dans des scénarios spécifiques, par exemple lors de l'utilisation de Hibernate. 
La valeur par défaut est des transactions de lecture et d'écriture.
 

Je suppose que tu aimes

Origine blog.csdn.net/qq_27828675/article/details/89514545
conseillé
Classement