Re: Inter-app communication via DB

On Thu, Jun 19, 2008 at 11:25 AM, Karsten Hilbert
<Karsten(dot)Hilbert(at)gmx(dot)net> wrote:
> 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.
>

Good point.

>> 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 ?

Another good point.

I have a small problem with this. If app1 wants to tell app2 to
perform an expensive operation (which you don't want app2 to do each
time it starts up), in the original pattern it could just set a
boolean variable. Now it needs to both set a boolean variable (in case
app2 isn't running at the moment) and use NOTIFY (for when it is),
which seems a bit redundant.

>
>> 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.

I don't mind threads in Python. It's mostly for C and C++ apps where I
don't want to add threading and an extra db connection to the code
just to be able to receive notifications from other apps.

For cases like that, your idea of a separate listener daemon will be
useful if there are a lot of instances that want to poll at the same
time :-)

David.