Choisir un niveau d’isolation adapté

Quand deux agents consultent et modifient les emprunts en même temps, une transaction peut lire une donnée qui va être annulée ou obtenir des résultats différents au fil de son traitement. Le niveau d’isolation détermine quelles variations une transaction peut observer. Vous allez comparer les quatre niveaux MariaDB et choisir celui qui convient à une lecture métier.

La leçon précédente a montré comment regrouper des opérations avec START TRANSACTION, COMMIT et ROLLBACK. Ici, vous vous concentrez sur les lectures concurrentes dans des tables InnoDB ; le niveau d’isolation ne remplace pas l’atomicité de la transaction.

Quatre niveaux, des lectures différentes

Une lecture sale expose à une transaction une modification non validée par une autre. Si l’autre transaction annule ensuite son changement, la première aura utilisé une valeur qui n’a jamais été définitivement enregistrée. READ UNCOMMITTED autorise ce risque ; il est rarement approprié pour le traitement des emprunts.

Une lecture non répétable survient lorsque la même ligne, relue pendant une transaction, présente une valeur différente après la validation d’une modification concurrente. READ COMMITTED évite les lectures sales, mais chaque lecture peut voir les changements validés depuis la lecture précédente. C’est une option utile si votre traitement accepte que son résultat évolue entre deux requêtes.

Une lecture fantôme apparaît quand une requête répétée sur un critère retrouve de nouvelles lignes, ou n’en retrouve plus, après une modification concurrente qui satisfait ce critère. Par exemple, un comptage d’emprunts non rendus peut changer après l’insertion ou la mise à jour validée d’un emprunt. Avec InnoDB, REPEATABLE READ fournit généralement une vue cohérente des lectures simples pendant une transaction ; SERIALIZABLE impose une isolation plus stricte, avec davantage de risques d’attente ou de conflits.

Observer une lecture non répétable

Pour observer ce phénomène, ouvrez deux sessions MariaDB sur la même base et choisissez un emprunt_id existant dans vos données. Dans la session A, fixez READ COMMITTED pour la prochaine transaction ; la session B modifiera puis validera la date de retour entre les deux lectures de A. Remplacez la valeur d’exemple par un identifiant présent dans votre base.

-- Session A : chaque lecture validée concurrente peut être visible.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;

-- Première lecture : relevez la valeur de date_retour.
SELECT emprunt_id, date_retour
FROM emprunts
WHERE emprunt_id = 1;

-- Exécutez la seconde lecture après le COMMIT de la session B.
SELECT emprunt_id, date_retour
FROM emprunts
WHERE emprunt_id = 1;

COMMIT;

Si la session B valide une modification entre les deux SELECT, la seconde lecture peut afficher une nouvelle valeur de date_retour. Adaptez emprunt_id = 1 à un emprunt existant.

-- Session B : lancez ces commandes entre les deux lectures de A.
START TRANSACTION;

UPDATE emprunts
SET date_retour = CURRENT_DATE
WHERE emprunt_id = 1;

COMMIT;

La session B valide une nouvelle date de retour pour l’emprunt ciblé. Utilisez un emprunt de test et restaurez son état si nécessaire.

Avec REPEATABLE READ, une lecture cohérente répétée dans la même transaction conserve normalement sa vue, même si une autre session valide ensuite une modification. Pour refaire l’expérience, terminez la transaction, sélectionnez le niveau avant d’en démarrer une nouvelle et relancez les lectures. N’interprétez pas ce résultat comme une protection universelle contre toutes les écritures concurrentes : les mises à jour et les lectures verrouillantes ont leurs propres règles.

Configurer le niveau adapté

SET TRANSACTION ISOLATION LEVEL choisit le niveau de la prochaine transaction pour la session. Placez cette instruction avant START TRANSACTION et adoptez la même discipline dans votre application. Pour un réglage durable de session, MariaDB propose aussi une syntaxe distincte ; évitez de la confondre avec la configuration ponctuelle illustrée ici.

-- Choisir un niveau pour la prochaine transaction.
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;

-- Lecture cohérente d’un emprunt existant.
SELECT emprunt_id, adherent_id, date_emprunt, date_retour_prevue, date_retour
FROM emprunts
WHERE emprunt_id = 1;

COMMIT;

La transaction lit les informations de l’emprunt selon le niveau sélectionné. Choisissez un identifiant existant dans votre base.

Choisissez READ COMMITTED si chaque instruction peut travailler sur les dernières données validées. Préférez souvent REPEATABLE READ lorsqu’une transaction doit relire une vue cohérente ; réservez SERIALIZABLE aux cas où cette garantie stricte justifie les conflits supplémentaires. READ UNCOMMITTED ne convient pas à une décision fondée sur des emprunts dont les modifications doivent être fiables.

Pour le prêt d’un exemplaire, le niveau d’isolation ne suffit pas à empêcher deux opérations concurrentes de choisir le même exemplaire disponible. La prochaine leçon traitera le verrouillage ciblé de la ligne concernée ; vous pourrez alors combiner une stratégie de lecture adaptée et une protection explicite de l’opération.

À retenir

• READ UNCOMMITTED peut exposer des modifications non validées ; évitez-le pour des décisions métier sensibles.
• READ COMMITTED évite les lectures sales, mais une même ligne peut changer entre deux lectures.
• REPEATABLE READ conserve généralement une vue cohérente pour les lectures répétées d’une transaction InnoDB.
• SERIALIZABLE renforce l’isolation, au prix d’attentes et de conflits potentiels.
• Définissez le niveau avant START TRANSACTION et vérifiez le comportement avec des essais sur deux sessions.