| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
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.)
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 |