SYS:ONLINE/PUBLICATIONS
BELGIQUE 🇧🇪/CLEARANCE:PUBLIC
RSS
JF FAFCHAMPSsMug@replicatorbe
~/Publications/Développement/transaction-introduction

Transaction : introduction

Développement / /2 min de lecture

Un groupe de requêtes SQL qui passent toutes, ou aucune. Start, commit, rollback, les propriétés ACID — et le rappel qui compte : une transaction ne remplace pas la gestion des exceptions.

Note ajoutée depuis : billet de 2009, en pleine période de cours. Trois ans plus tard, ce sont exactement ces beginTransaction() et commit() qu'on retrouve dans mon code Hibernate. La suite annoncée sur les quatre phénomènes indésirables n'a pas encore refait surface dans mes backups.

Transaction : groupe de requêtes SQL qui doivent toutes être menées à bien pour être validées.

Les transactions fournissent un moyen d'annuler un ensemble de requêtes SQL si l'une d'entre elles a échoué. Elles fournissent également un moyen d'isoler les données qu'un traitement devrait voir, de manière à éviter les surprises provenant d'autres traitements.

La norme SQL a introduit trois commandes importantes pour gérer une transaction :

  • start
  • commit
  • rollback

Rappel : construire une transaction ne remplace pas le mécanisme de gestion d'exceptions (orienté objet). Certaines requêtes pourraient ne pas s'exécuter correctement, il faudrait intercepter l'exception. En Java : try, catch, finally.

Dans un monde transactionnel parfait, les transactions devraient respecter les propriétés ACID :

  • Atomicité
  • Cohérence
  • Isolation
  • Durabilité

Exemple de transaction

start transaction
  lire(x)
  x = x - 5
  ecrire(x)
commit-transaction

Si tout s'est passé correctement, la transaction sera exécutée. Si une erreur survient dans une de ces lignes, toutes les lignes seront annulées.

Quels phénomènes indésirables peuvent se présenter ?

  1. La perte de mise à jour
  2. La lecture sale
  3. La lecture non reproductible
  4. La lecture fantôme

Nous y reviendrons dans un autre sujet de ce blog.