PostgreSQL - VERROUILLAGES

Serrures ou verrous exclusifs ou verrous d'écriture empêchent les utilisateurs de modifier une ligne ou d' une table. Les lignes modifiées par UPDATE et DELETE sont alors exclusivement verrouillées automatiquement pendant la durée de la transaction. Cela empêche les autres utilisateurs de modifier la ligne jusqu'à ce que la transaction soit validée ou annulée.

Le seul moment où les utilisateurs doivent attendre d'autres utilisateurs est lorsqu'ils essaient de modifier la même ligne. S'ils modifient différentes lignes, aucune attente n'est nécessaire. Les requêtes SELECT n'ont jamais à attendre.

La base de données effectue le verrouillage automatiquement. Dans certains cas, cependant, le verrouillage doit être commandé manuellement. Le verrouillage manuel peut être effectué à l'aide de la commande LOCK. Il permet de spécifier le type et la portée du verrou d'une transaction.

Syntaxe de la commande LOCK

La syntaxe de base de la commande LOCK est la suivante -

LOCK [ TABLE ]
name
 IN
lock_mode

  • name- Le nom (éventuellement qualifié du schéma) d'une table existante à verrouiller. Si ONLY est spécifié avant le nom de la table, seule cette table est verrouillée. Si ONLY n'est pas spécifié, la table et toutes ses tables descendantes (le cas échéant) sont verrouillées.

  • lock_mode- Le mode de verrouillage spécifie les verrous avec lesquels ce verrou est en conflit. Si aucun mode de verrouillage n'est spécifié, alors ACCESS EXCLUSIVE, le mode le plus restrictif, est utilisé. Les valeurs possibles sont: ACCESS SHARE, ROW SHARE, ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE, ACCESS EXCLUSIVE.

Une fois obtenu, le verrou est maintenu pour le reste de la transaction en cours. Il n'y a pas de commande UNLOCK TABLE; les verrous sont toujours libérés à la fin de la transaction.

DeadLocks

Des blocages peuvent survenir lorsque deux transactions attendent l'une l'autre pour terminer leurs opérations. Bien que PostgreSQL puisse les détecter et les terminer par un ROLLBACK, les blocages peuvent toujours être gênants. Pour éviter que vos applications ne rencontrent ce problème, assurez-vous de les concevoir de manière à ce qu'elles verrouillent les objets dans le même ordre.

Serrures consultatives

PostgreSQL fournit des moyens pour créer des verrous qui ont des significations définies par l'application. Celles-ci sont appelées verrous consultatifs . Comme le système n'impose pas leur utilisation, il appartient à l'application de les utiliser correctement. Les verrous consultatifs peuvent être utiles pour les stratégies de verrouillage qui ne conviennent pas au modèle MVCC.

Par exemple, une utilisation courante des verrous consultatifs est d'émuler des stratégies de verrouillage pessimistes typiques des systèmes de gestion de données dits "à fichier plat". Alors qu'un drapeau stocké dans une table pourrait être utilisé dans le même but, les verrous consultatifs sont plus rapides, évitent le gonflement de la table et sont automatiquement nettoyés par le serveur à la fin de la session.

Exemple

Considérez la table COMPANY ayant des enregistrements comme suit -

testdb# select * from COMPANY;
 id | name  | age | address   | salary
----+-------+-----+-----------+--------
  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 verrouille la table COMPANY dans la base de données testdb en mode ACCESS EXCLUSIVE. L'instruction LOCK ne fonctionne qu'en mode transaction -

testdb=#BEGIN;
LOCK TABLE company1 IN ACCESS EXCLUSIVE MODE;

L'instruction PostgreSQL donnée ci-dessus produira le résultat suivant -

LOCK TABLE

Le message ci-dessus indique que la table est verrouillée jusqu'à ce que la transaction se termine et que pour terminer la transaction, vous devrez annuler ou valider la transaction.