From: | Silvio Bravo Cadó <bravocado(at)gmail(dot)com> |
---|---|
To: | Álvaro Hernández Tortosa <aht(at)nosys(dot)es> |
Cc: | Espartano <espartano(dot)mail(at)gmail(dot)com>, postgre sql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: envio de sms |
Date: | 2011-09-13 21:29:55 |
Message-ID: | CAE57xEAU+jS3ugMe3hgxoPKiEPGtKXDAS_CCKGzNS-wry8-NUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Finalmente logre resolver el problema con un listen/notify. Un trigger
dispara una funcion que hace un notify y mientras tanto en perl tengo un
programa haciendo listen sobre la notificacion, cuando esta llega obtengo
los registros que estan marcados con enviados=false y envio el sms. Hasta
ahora todo ha ido muy bien, falta probarla con mas ruido.
Les agradezco de antemano sus comentarios.
Un saludo.
2011/9/12 Álvaro Hernández Tortosa <aht(at)nosys(dot)es>
> El 12/09/11 22:50, Espartano escribió:
>
> 2011/9/11 Álvaro Hernández Tortosa<aht(at)nosys(dot)es>:
>>
>>> El 09/09/11 17:05, Silvio Bravo Cadó escribió:
>>>
>>> Wow no habia escuchado sobre pgq, se ve interesante, aunque creo imho que
>>> es
>>> tambien meter logica de negocio dentro de la db, que para este caso no le
>>> veo problema ya sea por pgq o por listen/notify.
>>>
>>> Hola, Silvio (ahora sí, perdón por la lectura rápida de tu nombre).
>>> Yo
>>> no creo que eso sea meter lógica de negocio, es usar un sistema de colas
>>> (que, tangencialmente, usa una bbdd). De hecho, es muy común que un
>>> sistema
>>> de colas use una bbdd para la persistencia. Lo importante es que sea una
>>> aplicación la que, tras escribir en tu bbdd, comunique a la cola el
>>> mensaje.
>>> Y luego, otra app, lea de la cola y envíe el sms.
>>>
>> Aquí el problema de seguir ese esquema es: que pasaría si la
>> aplicación ya ha insertado en la base de datos y se pierde la
>> conectividad de red ? o se va la luz, o alguien pone un firewall hacia
>> la base de datos ?
>>
> Hola, yo no veo ningún problema. El mensaje se pasa a la cola de
> mensajes. Los sistemas de colas de mensajes garantizan la persistencia en
> los datos.
>
> Si te parece que se pudiera escribir en la db y se perdiera antes de
> llegar a la cola, siempre puedes: insertar db -> insertar cola -> actualizar
> en db que se ha insertado en cola.
>
>
>
>> Yo creo que para ese asunto es mejor que la db nofique al programa que
>> envía los sms que hay mensajes listos para ser enviados, si ocurre una
>> falla de energía o lo que sea lo mas que podría pasar es que enviaras
>> dos veces el mismo mensaje.
>>
> Enviar dos veces el mismo mensaje podría ser un problema (depende del
> caso de uso, yo lo desconozco). En todo caso, ¿qué sucede en tu caso si es
> la app la que no está disponible y la db intenta comunicarse con ella en un
> trigger? Eso no es muy bonito, tiene los mismos problemas que comentas.
>
> Cada misión, a su capa correspondiente. Lo que yo comenta no sufre de
> los problemas que sugieres.
>
>
> Saludos,
>
> Álvaro
>
> --
> Álvaro Hernández Tortosa
>
>
> -----------
> NOSYS
> Networked Open SYStems
>
>
--
*
Ing. Silvio Bravo Cadó*
Desarrollo de Software
*Tlaltek S.A de C.V* <http://tlaltek.com>
(229) 9 2 1 1 3 2 6 ext. 102.
Veracruz, México.
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2011-09-13 21:33:54 | Re: Mezclar datos + esquemas en otro server |
Previous Message | nestor | 2011-09-13 21:29:54 | Como evitar que postgrest genere series con "huecos" |