| From: | David <wizzardx(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Inter-app communication via DB |
| Date: | 2008-06-19 09:09:12 |
| Message-ID: | 18c1e6480806190209w4829f598re82b99267d4aa9af@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hi list.
One pattern I've used is for apps to communicate events to each other
through the database.
ie:
- 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?
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.
2) App 2 is usually single-threaded, and needs to do other things in
it's main thread besides wait for a DB notification.
I also know of RPC, but haven't used it before, and don't see a need
if you can use the above pattern.
I would use RPC (or unix signals if on the same host) if App 2 needed
to respond quickly, and I didn't want to hammer the DB & network with
constant polling.
Any comments?
David.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | coliban@gmail.com | 2008-06-19 09:22:56 | postgres generates too much processes per minute |
| Previous Message | David | 2008-06-19 08:15:26 | Re: Database design: Backwards-compatible field addition |