NOTIFY

Nombre

NOTIFY  --  Se�ala todos los "fronends" y "backends" a la escucha de una condici�n notify.

Synopsis

NOTIFY name        
  

Entradas

notifyname

Notifica la condici�n a ser se�alada.

Salidas

NOTIFY

Acuse de recibo de que el comando notify ha sido ejecutado.

Eventos Notify

Los eventos son repartidos a los "frontends" que est�n a la escucha; el c�mo y si cada aplicacion "frontend" reacciona depende de su programaci�n.

Descripci�n

El comando NOTIFY env�a un evento notify a cada aplicaci�n frontend que previamente ha ejecutado LISTEN notifyname para la condici�n notify espec�fica en la base de datos en curso.

La informaci�n pasada al "frontend" para un evento notify incluye el nombre de la condici�n notify y el PID de la notificaci�n del proceso "backend". Es asunto del dise�ador de la base de datos el definir los nombres de las condiciones que ser�n usadas en una base de datos dada y que significa cada una.

Comunmente, el nombre de una condici�n notify es el mismo que el de alguna tabla en la base de datos, y el evento notify esencialmente significa "He cambiado �sta tabla, echale un vistazo para ver los cambios". Pero dicha asociaci�n no es obligada por lo comandos NOTIFY y LISTEN. Por ejemplo, un dise�ador de bases de datos podr�a usar varios nombres de condici�n diferentes para se�alar diferentes tipos de cambios en una misma tabla.

NOTIFY provee un modo simple de se�alar o un mecanismo de comunicaci�n entre procesos (IPC interprocess communication) para el conjunto de procesos que acceden a la misma base de datos Postgres. Se pueden construir mecanismos de m�s alto nivel usando tablas en la base de datos para pasar datos adicionales (m�s all� de un mero nombre de condici�n) desde el notificador al o a los que est�n a la escucha.

Cuando se usa NOTIFY para se�alar la ocurrencia de cambios en una tabla en particular, una t�cnica �til de programaci�n es poner NOTIFY en una norma que es disparada por actualizaciones de la tabla. De esta manera, la notificaci�n es autom�tica cuando la tabla cambia, y el programador de la aplicaci�n no puede olvidarse de ello de forma accidental.

NOTIFY interact�a con transacciones SQL de una manera importante. Primero, si se ejecuta un NOTIFY dentro de una transacci�n, lo eventos notify no son repartidos hasta y a menos que la transacci�n se haya hecho. Esto es adecuado, dado que si una transacci�n se aborta nos gustar�a que todos los comandos dentro de ella no hubieran tenido efecto, incluyendo NOTIFY. Pero puede ser desconcertante si uno est� esperando que los eventos notify se repartan inmediatamente. Segundo, si un "backend" a la escucha recibe una se�al notify mientras est� en una transacci�n, el evento notify no se repartir� al "frontend" conectado hasta justo despu�s de que la transacci�n se haya completado (tanto si se ejecuta como si se aborta). De nuevo, la raz�n es que si un notify fuera repartido dentro de una transacci�n que despu�s fue abortado, ser�a deseable que la notificaci�n se deshiciera de alguna manera --- pero el "backend" no puede echar marcha atr�s un notify una vez que ha sido enviado al "frontend". Por tanto los eventos notify son s�lo repartidos entre transacciones. El resultado de �sto es que las aplicaciones que usan NOTIFY para se�alar en tiempo real deber�an tratar de mantener cortas sus transacciones.

NOTIFY se comporta como las se�ales Unix en un aspecto importante:si una misma condici�n es se�alada varias veces en una sucesi�n r�pida, los receptores puede que s�lo recibieran un evento notify para varias ejecucuiones de NOTIFY. Por ello es mala idea depender del n�mero de notificaciones recibidas. En cambio, usaremos NOTIFY para "despertar" a las aplicaciones que necesitan prestar atenci�n a algo, y usaremos un objeto de base de datos (tal como una secuencia) para mantener un registro de lo que ha ocurrido o cuantas veces ha ocurrido.

Es usual para un "frontend" que env�a NOTIFY estar �l mismo a la escucha del mismo nombre notify. En ese caso recibir� un evento notify , justo igual que los otros "frontends" a la escucha. Dependiendo de la l�gica de la aplicaci�n, esto podr�a acarrear un trabajo in�til --- por ejemplo, releyendo una tabla de una base de datos para encontrar la misma actualizaci�n que �se mismo frontend acababa de escribir. En Postgres 6.4 y posteriores , es posible evitar dicho trabajo extra notificando si el PID del proceso de notificaci�n del "backend" (suministrado en el mensaje del evento notify) es el mismo que el PID del backend de uno mismo (valga la redundancia) (disponible en libpq). Cuando son el mismo, el evento notificaci�n es la recuperaci�n del propio trabajo de uno mismo, y puede ser ignorado. (A pesar de lo que se dijo en el p�rrafo precedente, esto es una t�cnica segura. Postgres mantiene las auto-notificaciones separadas de las notificaciones que llegan de otros "backends", de manera que no puedes perder una notificaci�n de fuera por ignorar tus propias notificaciones.(Si alguien entiende �sto que me lo explique))

Notas

name puede ser una cadena v�lica com un nombre; no es necesar�a una relaci�n con el nombre de la tabla en s�. Si name se encierra entre dobles comillas, ni siquiera necesita un nombre sint�cticamente v�lido, sino que pude ser cualquier cadena de hasta 31 caracteres de longitud.

En algunas versiones previas de Postgres, name ten�a que encerrarse entre comillas dobles cuando no hab�a relaci�n con ning�n nombre de tabla existente, incluso si sint�cticamente era v�lido como nombre. Esto ya no es necesario.

En versiones Postgres anteriores a la 6.4, el PID de backend repartido en un mensaje notify era siempre el PID del backend del frontend de uno mismo. Por eso no se pod�a distinguir las notificaciones deuno mismo de las notificaciones de otros clientes en aquellas versiones.

Uso

Configura y ejecuta una secuencia listen(escucha)/notify(notificaci�n) desde psql:

LISTEN virtual;
NOTIFY virtual;
ASYNC NOTIFY de 'virtual' desde el pide de backend  '11239' recivido
   

Compatibilidad

SQL92

No hay sentenciaNOTIFY en SQL92.