Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 Запуск приложения по событию в БД  [new]
I.Tal
Member

Откуда:
Сообщений: 22
Здравствуйте! Посоветуйте, как лучше выполнить такую задачу: нужно, чтобы после того, как в таблице добавится строка (сработает триггер), происходил запуск приложения в винде (эти данные должны тут же в виде xml отправиться наверх с помощью приложения). Как это лучше сделать?
11 окт 18, 14:55    [21701663]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
I.Tal
Member

Откуда:
Сообщений: 22
Подскажите, хоть какие соображения, плз. Сейчас сделан опрос - т.е. коннект к базе каждые n минут - проверка, есть ли свежие данные. Хочется сделать по событию, т.к. данных может и не быть пару суток.
Есть еще такой вариант - в файл на диске записывать признак наличия информации, и уже любым планировщиком мониторить файлик - тогда избежим частых коннектов к базе.
15 окт 18, 14:59    [21704249]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4842
I.Tal,

Добрый день.

Внешним приложением/скриптом, запускаемым по расписанию периодически.
Триггер готовит данные для приложения, складывая их в таблицу-очередь.
Приложение соединяется с базой и обрабатывает очередь сообщений.
15 окт 18, 16:03    [21704311]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
CawaSPb
Member

Откуда: Питер/Москва/Wroclaw
Сообщений: 991
I.Tal,

Есть простое, очевидное, элегантное, но в большинстве случаев неправильное решение.
Можно сделать по внешним UDF/хранимой процедуре, но это в определённой степени извращение для таких задач. Тонкости вылезают с транзакционностью.
1) Транзакция "триггер" имеет полное право откатиться, а потом повториться (вызовет дубликаты событий). Способ бороться - транзакция-триггер - только вызывает приложение, сканирующее таблицу-очередь уже закоммиченных событий.
2) Обработчик события может не отработать по каким-то там причинам. Событие "пропадёт"

Планировщик же - самое оно. Единичные коннекты раз в N секунд/минут - очень недорогая операция (скорее проверка, превратившаяся в полный скан таблицы, может сожрать больше). Главное - смотрите, чтобы база активна была (activate database ...).
16 окт 18, 02:46    [21704663]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
I.Tal
Member

Откуда:
Сообщений: 22
Mark Barinstein

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


День добрый.
Как Вы думаете, данные в таблице-очереди должны ссылаться на большие таблицы, откуда приложение будет собирать всю информацию, или делать одну готовую таблицу-очередь?
И еще вопрос: можно ли создать процедуру, которая силами БД будет формировать xml, а приложение будет мониторить папку на наличие в ней файлов? Тогда наверняка придется столкнуться с транзакционностью, как пишет уважаемый CawaSPb.
16 окт 18, 15:06    [21705351]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
I.Tal
Member

Откуда:
Сообщений: 22
CawaSPb

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

Меня интересует - для общего развития - как сделать так, как Вы описали, где об этом почитать? Я понимаю, что это не совсем надежный вариант, но интересно, как это делается.

Планировщик же - самое оно. Единичные коннекты раз в N секунд/минут - очень недорогая операция (скорее проверка, превратившаяся в полный скан таблицы, может сожрать больше). Главное - смотрите, чтобы база активна была (activate database ...).

Таким образом, для проверки, есть ли данные вообще - составляю маленькую табличку, где буду хранить ссылки на большие таблицы, время появления информации и результат обработки.
16 окт 18, 15:16    [21705370]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
A.Panskikh
Member

Откуда: Москва
Сообщений: 114
I.Tal,

1. Идея с опросом таблиц является самой неправильной. Вам придется как-то синхронизировать 2 системы, понимая какие действия обработала внешняя система, какие нет. А если восстановили БД из бэкапа или рухнула принимающая система, возникает определенный геморрой.

Вариант решения: записываете события в таблицу, внешнее приложение "забирает" данные - ставит флаг или удаляет обработанные записи. Можно воспользоваться практически готовым решением - SQL replication.

2. Если откат транзакций не является критичным событием, можно обойтись, например, примитивным созданием флагов на файловой системе штатными функциями или написав/используя UDF.

3. Если транзакции критичны можно рассмотреть механизм CDC c MQ replication.

Andy
16 окт 18, 15:30    [21705408]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
Favn
Member

Откуда:
Сообщений: 567
Имхо, оптимально:

1. Буферная таблица с нумерацией (и / или таймштампом) записей.
Если XML делается на основе изменений и скорость позволяет - триггер пишет XML прямо в поле XML записей буфера.
Если создание XML требует комплексного поиска - в буфер пишем ссылки на данные, чтобы потом их обработать.
При OLTP триггер д.б. шустрым.
Транзакционная целостность соблюдается.

2. Отдельный сервис читает буфер и отправляет наружу что надо - фиксируя последнюю отправленную запись где-то у себя или в удаленном сервисе (он может просить данные "начиная с"). Если допускает бизнес и нужно много поиска по остальной базе - готовит отправку в периоды низкой нагрузки.

3. Когда записей в буфере станет много - нужен сборщик мусора в буфере, в периоды низкой нагрузки.

Остальные варианты требуют или платных фич (MQ), или внешних шин (JavaEE, например). И без буфера в базе придется решать проблему с возможным откатом транзакций - триггер сработал, а данных уже нет.
16 окт 18, 19:01    [21705773]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
I.Tal
Member

Откуда:
Сообщений: 22
Добрые люди, спасибо. Есть много информации к размышлению. Будет буферная таблица с таймштампом и отметкой выполненной операции, сервис отдельно, который мониторит буфер, собирает инфу и готовит файлы на отправку, сборщик мусора. Репликации не может быть - на принимающей стороне "черный ящик".

Одно осталось невыясненным: триггер, который вызывает приложение - подскажите, где об этом прочитать?
19 окт 18, 15:00    [21709227]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4842
I.Tal,

Добрый день.

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

Если очень надо, и это возможно, то заверните логику приложения в хранимую процедуру и вызывайте из триггера по событию. Но только не внешнее приложение.
19 окт 18, 18:06    [21709417]     Ответить | Цитировать Сообщить модератору
 Re: Запуск приложения по событию в БД  [new]
CawaSPb
Member

Откуда: Питер/Москва/Wroclaw
Сообщений: 991
I.Tal,

Mark Barinstein
Триггер не должен вызывать никаких приложений. Это опасный дизайн системы.
Триггер должен готовить данные для внешнего по отношению к базе приложения / скрипта, которое в свою очередь и должно вызывать нужное приложение.

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

Я бы сказал, что если очень-очень надо, то триггер (внешняя функция/хранимая процедура, дергаемая триггером) может запускать внешнее приложение, которое обладает определёнными характеристиками:
- приложение (код ф-и/процедуры) отрабатывает очень быстро и не делает НИЧЕГО.
- кромо как или а) посылает синал своей серверной части - "пора!", или б) запускает в параллель дополнительный процесс.

Та "серверная часть" не делает ничего, основываясь только на том факте, что "её позвали", а вновь лезет к базе и ищет дополнительную отметку, оставленную "запускающей" транзакцией.
- Если "запускающая" транзакция откатится, то запустившееся приложение ничего не обнаружит и тихо закроется.
- Пока "запускающая" транзакция не завершилась, "серверная часть" будет ждать в блокировке (надо сделать так, чтобы ждала).

Схема отодвинет вопрос согласованности транзакций лишь чуть дальше - приложение должно будет обеспечивать эту согласованность самостоятельно. Например, приложение может просто закрыться. Потому что может. Или потому что рубильник выключили. И т.п.

Схема имеет хоть какой-то смысл если вам действительно надо, чтобы по факту изменений что-то отрабатывало не через 5 секунд, и не через одну, а "вот прям сразу", и к архитектуре приложения, изменяющего базу, вы доступа не имеете.
И то, весьма вероятно, Q-Replication/CDC replication будут гораздо более надёжными средствами.
22 окт 18, 13:09    [21710979]     Ответить | Цитировать Сообщить модератору
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить