potap пишет:

> Спасибо, очень интересно, буду читать

Главное, почему НЕ НАДО так делать (так — это любым способом оповещать
клиентов об изменениях в БД) -- большое количество клиентов.
Если мы производим в единицу времени M транзакций изменения данных,
и имеем N клиентов, то в эту же единицу времени нам надо будет производить

o = N * M оповещений.

M на самом деле обычно тоже зависит от N, количества пользователей,
поскольку пользователи на сервере появляются не просто так, а чтобы что-то
делать. Допустим,

M = k * N (кол-во операций линейно зависит от кол-ва пользователей).

В таком случае оценка кол-ва оповещений будет

o = k * N**2

т.е. кол-во работы сервера по оповещению клиентов будет пропорционально
квадрату кол-ва клиентов. Это — очень плохо для масштабируемости системы.
Т.е. грубо говоря, для больших систем с высокой нагрузкой это просто
не будет работать.

Что касается конкретно предлагаемого решения — с KILL —
тут есть два недостатка

* kill внутри сервера не работает синхронно. Т.е. будет какая-то задержка.
(но это не сильно важно)

* при большой нагрузке клиенты тупо не успеют устанавливать соединения с
сервером, поскольку установка соединения — достаточно длительная операция.
Но, конечно, при вялом изменнеии данных схема работать будет.