Expliquez les niveaux d'isolation des transactions et celui que votre base de données utilise par défaut.

Les quatre niveaux sont read uncommitted, read committed, repeatable read et serializable, et ils échangent de la concurrence contre les anomalies qu'ils autorisent : lectures sales, lectures non répétables, lectures fantômes et write skew. PostgreSQL utilise read committed par défaut, où chaque instruction voit un instantané frais ; MySQL avec InnoDB utilise repeatable read, où toute la transaction voit un seul instantané. Serializable est le seul niveau qui garantit que le résultat correspond à un ordre sériel.

Ils vont de read uncommitted jusqu'à serializable, et chaque palier élimine une anomalie au prix d'un peu de concurrence. Read committed empêche les lectures sales mais chaque instruction obtient son propre instantané, donc la même requête exécutée deux fois dans une transaction peut renvoyer des lignes différentes. Repeatable read fige un instantané pour toute la transaction. Serializable garantit en plus que le résultat équivaut à exécuter les transactions les unes après les autres, ce que Postgres fait par suivi de prédicats, donc au lieu de bloquer il peut annuler une transaction et il faut être prêt à réessayer. Les valeurs par défaut comptent : Postgres est en read committed, InnoDB en repeatable read, ce qui surprend les gens qui passent de l'un à l'autre. Le bug que j'ai vraiment rencontré, c'était un write skew sur une table de réservations, où deux requêtes vérifiaient chacune qu'aucune réservation chevauchante n'existait, voyaient toutes les deux un instantané propre, et inséraient toutes les deux. Repeatable read n'aidait pas parce qu'elles écrivaient des lignes différentes. On a corrigé avec serializable plus une reprise, puis plus tard avec une contrainte d'exclusion, ce qui coûte moins cher.