Sécurité des transactions dans un trigger contenant plusieurs requêtes

Hello à tous

Je me pose une petite question à ce sujet, voilà:

J'ai un joli trigger dont je suis très fier, il commence par "BEGIN" et fini par "END", il contient plusieurs requêtes séparées par un point-virgule, et marche très bien a priori.
Mais je me demandais : quid de la sécurité transactionnelle réelle quand un trigger contient plusieurs requêtes ? Cela est-il full secure ? Le "BEGIN" et le "END" sont-ils bien destinés à cela (j'ai vu des "BEGIN TRANSACTION") ?

En effet la nature de mes requêtes suppose une sécurité transactionnelle complète, mais c'est aussi intéressant de façon générale.

Autre question très liée : existe-t-il un moyen permettant de "tester" cette sécurité (en lançant des insertions parallèles exactement au même moment) ?

Merci d'avance

#Developpez

Salut georgie2.

On ne met pas de "start transaction" dans un déclencheur.
De ce fait, si vous faites un "insert" dans un script mysql, c'est à ce moment là que vous devez faire votre "start transaction".
Il devra se terminer par un "commit" ou un "rollback" en fonction de la bonne exécution de votre "insert".

Donc l'acceptation (commit) ou le rejet (roolback) de votre "insert" sera global.

@+

Bonjour georgie2,

Quelques remarques et conseils sur la gestion transactionnelle à l'intérieur d'un trigger :

• Un trigger peut naturellement comporter plusieurs mises à jour de tables, ces mises à jour seront validées ou invalidées soit via un commit ou rollback prononcé explicitement par 'l'invoqueur' (celui qui a provoqué l’exécution du trigger) soit via le mode autocommit .
• Si un trigger ne doit effectivement pas comporter de 'start transaction', commit' ou 'rollback', je conseille vivement de gérer un contexte transactionnel à l'intérieur du trigger via des 'savepoint'/'rollback to savepoint'.
• En effet, quel que soit 'l'invoqueur', le trigger doit laisser une situation propre sur le plan transactionnel : soit toutes les mises à jours ont été réalisées soit rien n'a été réalisé. 'L'invoqueur' est alors protégé contre toute non gestion d'une anomalie survenue.
• Par ailleurs, il appartient en réalité à 'l'invoqueur' de décider de commiter ou rollbacker une transaction. En particulier on peut devoir décider de commiter une transaction, même si quelque chose s'est mal passé, notamment pour journaliser l’événement dans une table de log. Il faut donc donner à' l'invoqueur' les outils et moyens de gérer cela. Dans ce cas précis, il faut que le trigger ait :
  
  1. remis au propre les données qu'il a modifié (savepoint en entrée de trigger et rollback to savepoint à la détection de l'erreur),
  2. provoqué une exception pour que 'l'invoqueur' soit prévenu de du problème survenu et prenne la décision appropriée.