English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
Les verrous sont principalement utilisés pour maintenir l'uniformité des données de la base de données, pour empêcher les utilisateurs de modifier une ligne ou une table entière, généralement utilisés dans les bases de données avec un niveau de concurrence élevé.
Lorsque plusieurs utilisateurs accèdent à la base de données en même temps, sans contrôle des opérations concurrentes, il pourrait y avoir lecture et stockage de données incorrectes, endommageant l'uniformité de la base de données.
Il y a deux types de verrous de base dans la base de données : les verrous exclusifs (Exclusive Locks) et les verrous partagés (Share Locks).
Si l'objet de données est verrouillé de manière exclusive, d'autres transactions ne peuvent ni le lire ni le modifier.
Si un verrou partagé est ajouté, l'objet de base de données peut être lu par d'autres transactions, mais ne peut pas être modifié.
La syntaxe de base de la commande LOCK est la suivante :
LOCK [ TABLE ] name IN lock_mode
name : Le nom de la table existante à verrouiller (optionnel avec modèle limité). Si seul le nom de la table est spécifié, seule cette table est verrouillée. Si elle n'est pas spécifiée, la table et toutes ses sous-tables (si elles existent) sont verrouillées.
lock_mode : Le mode de verrouillage spécifie avec quel verrou le verrou en question entre en conflit. Si le mode de verrouillage n'est pas spécifié, le mode d'accès exclusif avec la restriction la plus grande est utilisé par défaut. Les valeurs possibles sont : ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE.
Une fois le verrou obtenu, il restera pendant le reste de la transaction en cours. Il n'y a pas de commande de déverrouillage de la table ; les verrous sont toujours libérés à la fin de la transaction.
Un verrouillage peut se produire lorsque deux transactions attendent que l'autre termine son opération. Bien que PostgreSQL puisse les détecter et les terminer par un rollback, les verrous sont néanmoins très désagréables. Pour éviter que l'application ne rencontre ce problème, assurez-vous que l'application est conçue pour verrouiller les objets dans un ordre identique.
PostgreSQL fournit des méthodes pour créer des verrous avec un sens défini par l'application. Ceux-ci sont appelés verrous consultatifs. Comme le système ne les impose pas, leur utilisation correcte dépend de l'application. Les verrous consultatifs sont très utiles pour les stratégies de verrouillage qui ne s'adaptent pas au modèle MVCC.
Par exemple, une utilisation courante de verrouillage consultatif est de simuler la stratégie de verrouillage pessimiste typique dans un système de gestion de données de "fichier plat" prétendu. Bien que les marqueurs stockés dans la table puissent être utilisés à la même fin, le verrouillage consultatif est plus rapide, évite l'expansion de la table et est nettoyé automatiquement par le serveur à la fin de la session.
Créer la table COMPANY (Télécharger le fichier SQL COMPANY ),le contenu des données est le suivant :
w3codeboxdb# select * from COMPANY; id | name | age | adresse | salaire ----+-------+-----+-----------+-------- 1 | Paul | 32 | California| 20000 2 | Allen | 25 | Texas | 15000 3 | Teddy | 23 | Norway | 20000 4 | Mark | 25 | Rich-Mond | 65000 5 | David | 27 | Texas | 85000 6 | Kim | 22 | South-Hall| 45000 7 | James | 24 | Houston | 10000 (7 rows)
L'exemple suivant montrera w3La table COMPANY de la base de données codeboxdb est verrouillée en mode ACCESS EXCLUSIVE.
Les instructions LOCK ne fonctionnent qu'en mode transaction.
w3codeboxdb=#BEGIN; LOCK TABLE company1 IN ACCESS EXCLUSIVE MODE;
L'opération ci-dessus produira le résultat suivant :
LOCK TABLE
Le message ci-dessus indique que la table est verrouillée jusqu'à la fin de la transaction, et pour terminer la transaction, vous devez annuler ou soumettre la transaction.