Re: LISTEN considered dangerous
От | Ian Harding |
---|---|
Тема | Re: LISTEN considered dangerous |
Дата | |
Msg-id | 725602300608011202n4c941bd4q951999d0db7beb30@mail.gmail.com обсуждение исходный текст |
Ответ на | LISTEN considered dangerous (Flemming Frandsen <ff@partyticket.net>) |
Ответы |
Re: LISTEN considered dangerous
Re: LISTEN considered dangerous |
Список | pgsql-general |
On 8/1/06, Flemming Frandsen <ff@partyticket.net> wrote: > I have an application that does aggresive caching of data pulled from > the database, it even keeps the objects cached between transactions. > > Normally this works very well and when the cache is warmed up about 90% > of the database time is saved. > > However that leaves the problem of how to notice that my cached objects > have turned stale, luckily pg has the listen/notify feature so I have > triggers on all tables that do a notify, as you do. > > However that just doesn't work, because listen is broken, allow me to > illustrate, here A and B are two clients: > > A: BEGIN > A: SELECT * FROM foo and cache the result. > A: LISTEN foochange > B: BEGIN > B: update foo > B: NOTIFY foochange > B: COMMIT > A: COMMIT > From the docs:. NOTIFY interacts with SQL transactions in some important ways. Firstly, if a NOTIFY is executed inside a transaction, the notify events are not delivered until and unless the transaction is committed. This is appropriate, since if the transaction is aborted, all the commands within it have had no effect, including NOTIFY. But it can be disconcerting if one is expecting the notification events to be delivered immediately.
В списке pgsql-general по дате отправления: