LOCK

Description

LOCK TABLE obtient un verrou de niveau table, attendant si n�cessaire que tous les verrous en conflit soient l�ch�s. Si NOWAIT est sp�cifi�, LOCK TABLE n'attend pas l'acquisition du verrou d�sir� : s'il ne peut pas �tre obtenu imm�diatement, la commande est annul�e et une erreur est �mise. Une fois obtenu, le verrou est gard� jusqu'� la fin de la transaction en cours. (Il n'y a pas de commande UNLOCK TABLE ; les verrous sont toujours abandonn�s � la fin de la transaction.)

Lors de l'acquisition automatique de verrous pour les commandes qui r�f�rencent des tables, PostgreSQL utilise toujours le mode de verrou le moins restrictif possible. LOCK TABLE est fourni pour les cas o� vous pourriez avoir besoin de verrous plus restrictifs. Par exemple, supposez qu'une application ex�cute une transaction au niveau d'isolation de lecture valid� (Read Committed) pour s'assurer que les donn�es de la table restent stables pendant la dur�e de la transaction. Pour r�aliser ceci, vous pouvez obtenir un mode de verrou SHARE sur la table avant d'envoyer la requ�te. Ceci emp�che toute modification concurrente des donn�es et assure que les lectures de la table voient une vue stable des donn�es valid�es parce que le mode de verrou SHARE est en conflit avec le verrou ROW EXCLUSIVE acquis par les modificateurs et votre instruction LOCK TABLE nom IN SHARE MODE attend jusqu'� ce que tous d�teneurs concurrents de verrous en mode ROW EXCLUSIVE valident ou annulent. Du coup, une fois le verrou obtenu, il ne reste aucune �criture en attente ; de plus, aucune ne peut commencer tant que vous n'avez pas supprim� le verrou.

Pour obtenir un effet similaire lors de l'ex�cution d'une transaction au niveau d'isolation s�rialisable, vous devez ex�cuter l'instruction LOCK TABLE avant d'ex�cuter toute instruction SELECT ou toute instruction de modification de donn�es. La vue des donn�es par une transaction s�rialisable des donn�es est gel�e � la premi�re instruction SELECT ou � la premi�re instruction de modification des donn�es. Un LOCK TABLE plus tard emp�che toujours les �critures concurrentes — mais il n'assure pas que ce que la transaction lit correspond aux derni�res donn�es valid�es.

Si une transaction de cette sorte va modifier les donn�es de la table, alors elle doit utiliser le mode de verrou SHARE ROW EXCLUSIVE au lieu du mode SHARE. Ceci nous assure que seule une transaction de ce type est en ex�cution � la fois. Sans cela, un verrou mortel est possible : deux transactions pourraient acqu�rir � la fois le mode SHARE et �tre ensuite incapable d'acqu�rir aussi le mode ROW EXCLUSIVE pour r�ellement effectuer leur mises � jour. (Notez que les propres verrous d'une transaction ne sont jamais en conflit, donc une transaction peut acqu�rir le mode ROW EXCLUSIVE lorsqu'il tient le mode SHARE — mais pas si quelqu'un d'autre d�tient le mode SHARE.) Pour �viter les verrous bloquants, assurez-vous que toutes les transactions acqui�rent des verrous sur les m�mes objets dans le m�me ordre, et si des modes multiples de verrous sont impliqu�s pour un seul objet, alors les transactions doivent toujours acqu�rir en premier le mode le plus restrictif.

Plus d'informations sur les modes de verrou et les strat�gies de verrouillage sont disponibles dans Section 12.3.

Param�tres

Notes

LOCK TABLE ... IN ACCESS SHARE MODE requiert les droits SELECT sur la table cible. Tous les autres formats de LOCK requi�rent les droits UPDATE et/ou DELETE.

LOCK TABLE est utile seulement dans un bloc de transaction (paire BEGIN/COMMIT), car le verrou est supprim� aussit�t que la transaction se termine. Une commande LOCK apparaissant � l'ext�rieur de tout bloc de transaction forme une transaction contenue dans elle-m�me, donc le verrou est supprim� d�s qu'il est obtenu.

LOCK TABLE s'occupe seulement des verrous au niveau table et du coup, les noms de mode impliquant ROW sont tous mal nomm�s. Ces noms de modes doivent g�n�ralement �tre compris comme indiquant l'intention de l'utilisateur d'acqu�rir des verrous de niveau ligne � l'int�rieur de la table verrouill�e. De plus, le mode ROW EXCLUSIVE est un verrou de table partageable. Gardez en t�te que tous les modes de verrou ont des s�mantiques identiques en ce qui concerne LOCK TABLE, diff�rant seulement dans les r�gles de conflit entre les modes. Pour des informations sur la fa�on d'acqu�rir un r�el verrou au niveau ligne, voir Section 12.3.2 et Clause FOR UPDATE dans la documentation de r�f�rence de SELECT.

Exemples

Obtenir un verrou SHARE sur une table avec cl� primaire avant de r�aliser des insertions dans une table disposant de la cl� �trang�re :

BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
    WHERE nom = 'Star Wars: Episode I - The Phantom Menace';
-- Effectuer un ROLLBACK si aucun enregistrement n'est retourn�
INSERT INTO commentaires_films VALUES 
    (_id_, 'SUPER ! Je l''attendais depuis si longtemps !');
COMMIT WORK;

Prendre un verrou SHARE ROW EXCLUSIVE sur une table avec cl� primaire lors du d�but des op�rations de suppression :

BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM commentaires_films WHERE id IN
    (SELECT id FROM films WHERE score < 5);
DELETE FROM films WHERE score < 5;
COMMIT WORK;

Compatibilit�

LOCK TABLE n'existe pas dans le standard SQL, qui utilise � la place SET TRANSACTION pour sp�cifier des niveaux de concurrence sur les transactions. PostgreSQL a aussi cela ; voir SET TRANSACTION pour les d�tails.

Sauf pour les modes de verrous ACCESS SHARE, ACCESS EXCLUSIVE et SHARE UPDATE EXCLUSIVE, les modes de verrou PostgreSQL et la syntaxe LOCK TABLE sont compatibles avec ceux pr�sents dans Oracle.