LISTEN — Attendre une notification
LISTEN canal
LISTEN
enregistre la session courante comme listener du
canal de notification canal
.
Si la session courante est déjà enregistrée comme listener de ce canal de
notification, il ne se passe rien de plus.
À chaque appel de la commande NOTIFY
, que ce soit par cette
session ou par une autre connectée à la même base de données, toutes les
sessions attendant sur ce canal en sont avisées et chacune en avise en
retour son client. Voir canal
NOTIFY
pour plus d'informations.
La commande UNLISTEN
permet d'annuler l'enregistrement
d'une session comme listener d'un canal de notification. Les
enregistrements d'écoute d'une session sont automatiquement effacés lorsque
la session se termine.
La méthode utilisé par un client pour détecter les événements de
notification dépend de l'interface de programmation
PostgreSQL qu'il utilise. Avec la bibliothèque
libpq, l'application exécute
LISTEN
comme une commande SQL ordinaire, puis appelle
périodiquement la fonction PQnotifies
pour savoir si
un événement de notification est reçu. Les autres interfaces, telle
libpgtcl, fournissent des méthodes de plus haut
niveau pour gérer les événements de notification ; en fait, avec
libpgtcl, le développeur de l'application n'a
même pas à lancer LISTEN
ou UNLISTEN
directement. Tous les détails se trouvent dans la documentation de
l'interface utilisée.
canal
Le nom d'un canal de notification (tout identifiant).
LISTEN
prend effet à la validation de la transaction. Si
LISTEN
ou UNLISTEN
est exécuté dans
une transaction qui sera ensuite annulée, l'ensemble des canaux de
notification écoutés sera inchangé.
Une transaction qui a exécuté LISTEN
ne peut pas être
préparée pour la validation en deux phases.
Il existe une fenêtre de vulnérabilité lors de la mise en place d'une
session d'écoute : si des transactions validant en concurrence
envoient des notifications, quels sont celles que la nouvelle session
en écoute va recevoir ?
La réponse est que la session recevra tous les événements validés après un
instant lors de l'étape de validation de la transaction. Mais c'est
légèrement plus tard que n'importe quel état de base de données qu'aurait pu
observer une transaction avec des requêtes. Cela conduit à la règle suivante
pour l'utilisation de LISTEN
: exécutez d'abord
(et validez !) cette commande, puis dans une nouvelle transaction, inspectez
l'état de la base de données selon les besoins de la logique de
l'application. Ensuite, utilisez les notifications pour connaître les
modifications ultérieures de l'état de la base de données. Les premières
notifications reçues peuvent faire référence à des mises à jour déjà
constatées lors de l'inspection initiale de la base de données, mais cela est
généralement sans conséquence.
NOTIFY contient une discussion plus étendue sur
l'utilisation de LISTEN
et NOTIFY
.
Configurer et exécuter une séquence listen/notify à partir de psql :
LISTEN virtual; NOTIFY virtual; Notification asynchrone "virtual" reçue en provenance du processus serveur de PID 8448.
Il n'existe pas d'instruction LISTEN
dans le standard
SQL.