| Documentation PostgreSQL 7.4.29 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
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.)
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.
| Précédent | Sommaire | Suivant |
| MOVE | Niveau supérieur | PREPARE |