Réponse.

Historique de la question

Avec l'émergence des bases de données multi-utilisateurs, le besoin de limiter la modification simultanée des mêmes données s'est posé. Cela a conduit à l'apparition de divers mécanismes de verrouillage (gestion des verrous), qui empêchent les modifications parallèles et aident à maintenir l'intégrité des données.

Problème

Sans contrôle d'accès, les opérations simultanées peuvent entraîner des dommages ou des pertes de données : par exemple, deux transactions mettent à jour simultanément une même ligne, et les modifications d'une transaction sont perdues. Des verrous trop laxistes entraînent des problèmes de concurrence (conditions de course), tandis qu'un excès de verrous peut entraîner des pertes de performance (verrouillages, contention).

Solution

Dans les SGBD modernes, il existe des niveaux de verrouillage (niveau ligne, niveau page, niveau table) et différents modes (partagé, exclusif, mise à jour). Le programmeur peut gérer cela via les paramètres d'isolation des transactions et des commandes de verrouillage explicites (par exemple, SELECT ... FOR UPDATE).

Exemple de code :

-- Verrouillage de la ligne jusqu'à la fin de la transaction
BEGIN TRANSACTION;
SELECT * FROM users WHERE id = 1 FOR UPDATE;
UPDATE users SET name = 'New Name' WHERE id = 1;
COMMIT;

Caractéristiques clés :

Granularité du verrouillage (ligne, page, table)
Verrous explicites et implicites (via des transactions et des instructions spéciales)
Impact du niveau d'isolation sur le schéma de verrouillage

Questions pièges.

Quelle est la différence entre un verrou de lecture (verrou partagé) et un verrou d'écriture (verrou exclusif) ?

Le verrou partagé permet à plusieurs transactions de lire les données simultanément, mais n'autorise pas les modifications. Le verrou exclusif permet à une seule transaction de modifier les données, et interdit l'accès aux autres.

Une commande SELECT peut-elle provoquer un verrouillage ?

En général, SELECT ne provoque pas de verrouillages, mais l'utilisation de SELECT ... FOR UPDATE ou un niveau d'isolation élevé (par exemple, SERIALIZABLE) peut amener le SGBD à verrouiller les lignes.

Exemple de code :

SELECT * FROM products WHERE id = 10 FOR UPDATE;

Les verrous protègent-ils toujours contre les "mises à jour perdues" ?

Non, si le niveau de verrouillage ou d'isolation est mal choisi, on peut rencontrer des "mises à jour perdues" — lorsque les modifications d'une transaction sont perdues en raison d'une autre. Il est essentiel de choisir soigneusement les mécanismes de gestion de la concurrence.

Erreurs classiques et anti-patterns

Mauvais choix du niveau d'isolation (trop bas ou trop élevé)
Verrous insuffisamment explicites dans les requêtes critiques
Abus des verrous globaux (niveau table) entraînant une chute de performance
Non-libération des verrous en raison de transactions inachevées

Exemple de la vie réelle

Cas négatif

Dans le département d'analyse, deux programmes mettent à jour simultanément les statuts des commandes. Pour accélérer, le niveau READ UNCOMMITTED a été spécialement choisi pour ne pas verrouiller les lignes. Cela a conduit à des conflits et à des "mises à jour perdues", certains données ont été corrompues.

Avantages :

Bonne vitesse au départ

Inconvénients :

Perte/corruption de données essentielles
Difficultés de récupération

Cas positif

Dans le département des ventes, les points critiques ont été enveloppés dans TRANSACTION + SELECT ... FOR UPDATE. Ils ont distingué les opérations de lecture et de mise à jour au niveau des lignes.