NOTIFY

Description

La commande NOTIFY envoie un �v�nement de notification � chaque application cliente qui a ex�cut� pr�c�demment la commande LISTEN nom pour le nom de notification sp�cifi� dans la base de donn�es courante.

NOTIFY fournit une simple forme de signal ou un m�canisme de communication interprocessus pour une collection de processus acc�dant � la m�me base de donn�es PostgreSQL. Des m�canismes de haut niveau peuvent �tre construit en utilisant les tables dans la base de donn�es pour passer des donn�es suppl�mentaires (en plus d'un simple nom de notification) du notifieur aux �couteurs.

L'information pass�e au client pour un �v�nement de notification inclut le nom de notification et le PID du processus serveur de la session le notifiant. C'est au concepteur de la base de donn�es de d�finir les noms de notification qui sont utilis�s dans une base de donn�es donn�e et ce que chacun signifie.

Habituellement, le nom de notification est le m�me que le nom d'une table dans la base de donn�es. L'�v�nement notify signifie essentiellement <<�J'ai modifi� cette table, jetez-y un œil pour v�rifier ce qu'il y a de nouveau�>>. Mais cette signification n'est pas impos�e par les commandes NOTIFY et LISTEN. Par exemple, un concepteur de bases de donn�es pourrait utiliser plusieurs noms de notification diff�rentes pour signaler diff�rentes sortes de modifications vers une seule table.

Lorsque NOTIFY est utilis� pour signaler l'occurrence des modifications pour une table particuli�re, une technique de programmation utile est de placer le NOTIFY dans une r�gle qui est d�clench�e par les mises � jour de table. De cette fa�on, la notification arrive automatiquement quand la table est modifi�e et le programmeur d'application ne peut oublier accidentellement de le faire.

NOTIFY interagit fortement avec les transactions SQL. Tout d'abord, si un NOTIFY est ex�cut� � l'int�rieur d'une transaction, les �v�nements notify ne sont pas d�livr�s jusqu'� ce que et � condition que la transaction soit valid�e. Ceci est appropri� car, si la transaction est annul�e, toutes les commandes qu'elle contenait sont annul�es, y compris NOTIFY. Mais, cela peut �tre d�concertant si on s'attend � ce que les �v�nements de notification soient d�livr�s imm�diatement. Ensuite, si une session en �coute re�oit un signal de notification alors qu'il est � l'int�rieur d'une transaction, l'�v�nement de notification n'est pas d�livr� au client connect� tant que la transaction n'est pas termin�e (soit valid�e soit annul�e). Encore une fois, le raisonnement est que si une notification a �t� d�livr�e � l'int�rieur d'une transaction qui a �t� finalement annul�e, on voudrait que la notification soit annul�e — mais le serveur ne peut pas <<�r�cup�rer�>> une notification une fois qu'elle a �t� envoy�e au client. Donc, les �v�nements de notification sont seulement d�livr�s entre les transactions. Ce qui en d�coule est que les applications utilisant NOTIFY pour des signaux en temps r�el doivent essayer d'avoir des transactions courtes.

NOTIFY se comporte comme les signaux Unix sur un seul point : si le m�me nom de notification est signal� plusieurs fois en des successions rapides, il est possible que les r�cepteurs ne re�oivent qu'un seul �v�nement de notification pour plusieurs ex�cutions de NOTIFY. Donc, c'est une mauvaise id�e de d�pendre du nombre de notifications re�ues. � la place, utilisez NOTIFY pour r�veiller vos applications qui ont besoin de faire attention � quelque chose et utilisez un objet de bases de donn�es (tel qu'une s�quence) pour garder trace de ce qui s'est pass� ou du nombre de fois o� cela s'est pass�.

Il est courant pour un client qui ex�cute NOTIFY d'�couter le m�me nom de notification lui-m�me. Dans ce cas, il r�cup�re un �v�nement de notification, comme toutes les autres sessions en �coute. Suivant la logique de l'application, ceci pourrait r�sulter en un travail inutile, par exemple lire une table de la base de donn�es pour trouver les m�mes mises � jour que cette session a �crit. Il est possible d'�viter un travail suppl�mentaire verifiant si le PID du processus serveur de la session notifiante (fourni dans le message d'�v�nement de la notification) est le m�me que le PID sur process serveur de sa propre session (disponible � partir de libpq). Quand ils sont identiques, l'�v�nement de notification est le retour de son propre travail et peut �tre ignor�. (En d�pit de ce qui est dit dans le pr�c�dent paragraphe, c'est une technique s�re. PostgreSQL distingue les notifications propres des notifications arrivant des autres sessions, de fa�on � ne pas oublier une notification externe en ignorant vos propres notifications.)

Param�tres

Exemples

Configure et ex�cute une s�quence listen/notify � partir de psql :

LISTEN virtual;
NOTIFY virtual;
Asynchronous notification "virtual" received from server process with PID 8448.

Compatibilit�

Il n'y a pas d'instruction NOTIFY dans le standard SQL.

Voir aussi