Une transaction regroupe plusieurs opérations SQL en une seule unité indivisible : soit toutes les opérations réussissent, soit aucune n'est appliquée. C'est essentiel dès qu'une opération métier touche plusieurs tables — comme un virement bancaire.
A transaction groups several SQL operations into a single, indivisible unit: either all operations succeed, or none are applied. This is essential whenever a business operation touches multiple tables — like a bank transfer.
BEGIN, COMMIT, ROLLBACK
BEGIN, COMMIT, ROLLBACK
BEGIN;
UPDATE comptes SET solde = solde - 100 WHERE id = 1;
UPDATE comptes SET solde = solde + 100 WHERE id = 2;
COMMIT;BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;Si une erreur survient entre les deux UPDATE (panne, contrainte violée, etc.), on peut annuler l'ensemble avec ROLLBACK plutôt que COMMIT, et le solde des deux comptes reste inchangé.
If an error occurs between the two UPDATEs (outage, violated constraint, etc.), you can undo everything with ROLLBACK instead of COMMIT, and both account balances remain unchanged.
BEGIN;
UPDATE comptes SET solde = solde - 100 WHERE id = 1;
-- une erreur est détectée ici
ROLLBACK;
-- aucun changement n'est appliquéBEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- an error is detected here
ROLLBACK;
-- no changes are appliedLes propriétés ACID
The ACID Properties
| Propriété | Signification |
|---|---|
| Atomicité | Toutes les opérations d'une transaction réussissent ensemble, ou aucune n'est appliquée |
| Cohérence | La base passe d'un état valide à un autre état valide, en respectant toutes les contraintes |
| Isolation | Deux transactions concurrentes ne se perturbent pas l'une l'autre |
| Durabilité | Une fois validée (COMMIT), la transaction survit même à une panne du serveur |
| Property | Meaning |
|---|---|
| Atomicity | All operations in a transaction succeed together, or none are applied |
| Consistency | The database moves from one valid state to another valid state, respecting all constraints |
| Isolation | Two concurrent transactions don't interfere with each other |
| Durability | Once committed (COMMIT), the transaction survives even a server crash |
Pourquoi l'isolation est délicate
Why Isolation Is Tricky
Quand plusieurs transactions s'exécutent en même temps, plusieurs problèmes peuvent survenir sans un niveau d'isolation adéquat :
When multiple transactions run at the same time, several problems can occur without an adequate isolation level:
- Lecture sale (dirty read) : lire des données modifiées par une transaction non encore validée
- Lecture non répétable : relire la même ligne deux fois dans une transaction et obtenir des valeurs différentes
- Lecture fantôme (phantom read) : une même requête renvoie un nombre de lignes différent à deux moments de la même transaction
- Dirty read: reading data modified by a transaction that hasn't been committed yet
- Non-repeatable read: reading the same row twice within a transaction and getting different values
- Phantom read: the same query returns a different number of rows at two points within the same transaction
Les niveaux d'isolation standards
The Standard Isolation Levels
| Niveau | Protège contre |
|---|---|
| READ UNCOMMITTED | Rien (le plus permissif) |
| READ COMMITTED | Lectures sales |
| REPEATABLE READ | Lectures sales + lectures non répétables |
| SERIALIZABLE | Tous les problèmes ci-dessus (le plus strict) |
| Level | Protects Against |
|---|---|
| READ UNCOMMITTED | Nothing (most permissive) |
| READ COMMITTED | Dirty reads |
| REPEATABLE READ | Dirty reads + non-repeatable reads |
| SERIALIZABLE | All of the above (strictest) |
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- opérations sensibles à la concurrence
COMMIT;SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;
-- concurrency-sensitive operations
COMMIT;Points clés à retenir
Key Takeaways
- Enveloppez toujours les opérations liées (ex. transfert d'argent) dans une transaction explicite
- Gardez les transactions courtes pour limiter les verrous et les conflits
- Testez votre code applicatif avec des
ROLLBACKvolontaires pour vérifier qu'aucune donnée partielle n'est écrite
- Always wrap related operations (e.g., a money transfer) in an explicit transaction
- Keep transactions short to limit locks and conflicts
- Test your application code with deliberate
ROLLBACKs to confirm no partial data gets written