Neil Conway <nconway@klamath.dyndns.org> writes:
> My impression (I could be wrong) is that LISTEN/NOTIFY doesn't get
> the press that it deserves. If this model isn't widely used because
> of some deficiencies in the LISTEN/NOTIFY implementation, IMHO our
> time would be better spent fixing those problems than implementing
> the proposed caching scheme.
I would have to say I think a large part of the problem is lack of
press---I've been hanging around pgsql-hackers for two or three years
now, and until all this discussion, had never heard of LISTEN/NOTIFY.
That doesn't mean I didn't miss prior mentions, but it certainly
doesn't seem to come up often or get a lot of discussion when it does.
Now that I know about it, well, it looks like it would be trivial to
use it to implement cache invalidation logic in my HTML::Mason-based
application---I need only have a long-lived process running on the web
server(s) that uses the perl Pg interface, and sits listening, and
when it sees notifies on given conditions, flush the appropriate local
caches.
I'd actually been contemplating cramming logic to do this down into
the library I use for implementing the system logic, but had resisted
doing it because it would make the library too tied to the web---this
would be much easier.
I won't even have to re-grab the results from the DB and reformat and
all that crap, I can just spew the output from the last time the page
was assembled---sounds better to me than what MySQL provides. Of
course, I get a lot of this for free as a result of the tools I'm
using, but surely this sort of thing shouldn't be all that hard to
implement in other systems.
Mike.
