Здравствуйте!
Вот уперся в задачу примерно такого содержания. Есть производственный процесс использующий скоропортящееся сырье. Сам процесс не детерминирован, т.е не равномерен по времени. Четко спрогнозировать необходимость в сырье не возможно. Количество сырья находится в таблице постгреса. Как просигнализировать клиенту ответственному за пополнение запасов о приближении к критическому минимальному количеству, используя стандартное API? Или стоит смотреть в сторону Интербейса/Файрберда?  

где тут java?

И где здесь PostgreSQL? Что такого он не умеет, чтобы это нельзя было реализовать?

Ок... В firebirde я нарыл способность, решающую мою проблему на все 100%. Это возможность передать клиенту в синхронном/асинхронном режиме событие, которое произошло в базе. Там есть оператор POST_EVENT для этого (стр 710 Руководство разработчика баз данных "FireBird" автора Хелен Борри, 2 издание). Вызывается от из триггера или ХП. Явовский клиент коннектится через JayBird JCA-JDBC драйвер и вешает слушателя через менеджер FBEventManager. Ну и так далее... Но беда в том, что свой проект я начал в Постгресе и слазить с него сейчас уже поздно. Да и членораздельная дока по файрберду недавно появилась... Да и такая задача внезапно как снег на голову... Вот и уперся. У меня есть идея как это реализовать, но сложно получается...
Надо будет рядом с постгресом положить серверный процесс который откроет порт для регистрации заинтересованного клиента, создать системную таблицу куда пишутся нужные мне изменения... серверный процесс непрерывно сканирует эту таблицу и отправляет через другой открытый порт уведомление зарегистрированному клиенту. В свою очередь на клиенте нужно организовать отдельный тред где постоянно прослушивать серверный процесс... и так далее... Вот и я спрашиваю... Возможно ли отловить событие как нибудь проще... Может уже кто то на эти грабли наступал 

Действительно какой-то ужос. 

В PostgreSQL можно писать триггеры на Java: http://wiki.tada.se/display/pljava/Home. Никаким серверным процессом сканировать таблицу не надо - триггер можно повесить на любые события в таблице. Поскольку Java, думаю есть возможность поработать с JMS. На очередь JMS вешаем обрабочик, который будет разруливать ситуацию. На первый взгляд выглядит все просто, не знаю как будет в реализации.

Во! Сегодня на ночь почитаем про JMS . Спасибо за совет!

Вообще, это довольно стандартное решение - сканирующий серверный процесс. У нас хоть и Oracle, который имеет свои механизмы сигнализации, но всё равно в ряде случаев используется этот подход, поскольку решено было, что так в некоторых случаях сделать удобнее. Только не непрерывно сканирует, а, скажем, раз в 5-10 минут опрашивает нужную таблицу и если нужные изменения фиксирует, отправляет JMS-сообщение, письмишко админу, какой-то метод где-то вызывает или web-сервис дёргает - на твой выбор...

Это не очень сложно.

P.S. Единственное неудобство - это отладка. В случае чего ждать, когда же он выполнит запрос после того, как ты положил данные в таблицу, несколько утомительно...

привет, maxlab.
се ля ви прав - можно опрашивать базу (polling) на предмет изменений.

но есть еще один вариант, которого ты коснулся - callback от субд, т.е. когда база сама дернет твое приложение при изменениях. тут вот какая фича: при соединении с внешней системой с помощью J2CA-адаптера так можно делать (но возможность callback-ов появилась в спецификации J2CA1.5, в версии 1.0 такого не было), а стандарте JDBC2 такой возможности нет.

мораль: если найдешь 1.5-адаптер для нужной тебе субд, можешь юзать callbacks стандартным способом. 

 

Почитал про JMS.... обещания однако впечатляют. Решил в Постгрес pljava пока не вкручивать, буду выкручиваться отдельным серверным процессом рядом с БД, дергающим JMS сервис. Сразу возник вопрос - из каких программных компонентов можно создать минимальную конфигурацию чтобы начать эксперименты с JMS? Что нужно дополнительно прикрутить на сервер где крутится постгрес, и на клиента? JDK 6u1 SE проинсталирована везде. 
На сим этот топик можно прикрыть. Остальные вопросы буду задавать в разделе J2EE   

Можно взять какую-нибудь standalone реализацию JMS, OpenJMS, например. На клиенте нужны какие-то клиентские библиотеки из него же. 

ok, спасибо