NOTIFY

Description

La commande NOTIFY envoie un �v�nement de notification pour 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.

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 seront utilis�s dans une base de donn�es indiqu�e et ce qu'elle signifie.

Habituellement, le nom de notification est le m�me que le nom de quelques tables 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 aucune association n'est renforc�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.

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

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 avec des transactions SQL de quelques fa�ons importantes. 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 en interne n'ont eu aucun effet, en incluant NOTIFY. Mais, cela peut �tre d�concertant si vous vous attendez � ce que les �v�nements de notification ne peuvent �tre 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 ne sera pas d�livr� au client connect� tant que la transaction ne sera pas termin�e (soit valid�e soit annul�e). Encore une fois, le raisonnement est que si une notification a �t� d�livr� � l'int�rieur d'une transaction qui a �t� annul� apr�s, vous pourriez vouloir que la notification soit annul�e d'une certaine fa�on --- mais le serveur ne pourrait 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 devraient essayer de raccourcir leurs transactions.

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, les r�cepteurs pourraient ne recevoir 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�us. � 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 habituel pour un client qui ex�cute NOTIFY d'�couter le m�me nom de notification lui-m�me. Dans ce cas, il r�cup�rera 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 en indiquant si le PID du processus serveur de la session notifiante (fournie dans le message d'�v�nement de la notification) est le m�me que celui du PID 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�. (Bien qu'il soit dit dans le pr�c�dent paragraphe, c'est une technique saine. PostgreSQL conserve les propres notifications s�par�es 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