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
