On Thu, Jun 19, 2008 at 11:09:12AM +0200, David wrote:
> One pattern I've used is for apps to communicate events to each other
> through the database.
Works nicely with LISTEN/NOTIFY. We use it a lot in GNUmed.
> - App 1 sents a boolean value to True
> - App 2 queries the field every 10s, sets the value to False, and does
> something.
>
> Is this reasonable, or should apps avoid this pattern?
Add more app instances and you'll have a lot of polling.
> I have seen the NOTIFY and LISTEN SQL statements. However:
>
> 1) App 2 might not be running at the time (eg: it's launched from
> cron, or it was temporarily stopped), and the expectation is that App
> 2 will run the special logic when it is started.
That will happen anyway, no matter what the message
transport is like. Apps will have to read state at startup
anyway, no ?
> 2) App 2 is usually single-threaded, and needs to do other things in
> it's main thread besides wait for a DB notification.
Well, threads in Python aren't *that* hard to get right. But
you could also write a small listener demon which gets
started on behalf of the local app instance which writes to
a local watch file which is being polled by the local app
instance. Takes the poll pressure off the database and
avoids having to thread the app, too.
There's a bunch of Python code here
http://cvs.savannah.gnu.org/viewvc/gnumed/gnumed/client/pycommon/gmBackendListener.py?root=gnumed&view=markup
that might be of interest.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
