Альтернатива post

← →
int64 © (2002-05-24 08:41) [0]

Помогите реализовать хороший аналог post_event/TEventAlerter.

Хороший в смысле:
1. Не глючит.
2. Не требует обязательной регистрации событий в клиенте. Т.е. может принимать абсолютно все сообщения.
3. И самое главное помимо сообщений может сразу принимать данные.

Мыслю так. На стороне сервера всё реализуется в виде UDF. Она принимает входные параметры и отсылает их посредством TServerSocket клиентам. На клиенте соответственно TClientSocket.

Теперь исходя из этого вопрос. Можно ли зашить такую (или какую подобную) передачу данных в коннекты, сессии,... короче, внутренности IB. Чтобы все манипуляции в дезайнтайм свелись к вызову в триггерах/SP UDF, а на клиенте помещением на форму компонента.

← →
Alexandr © (2002-05-24 10:20) [1]

ага, только udf будут срабатывать сразу, а не после commit, как events

← →
younghacker (2002-05-24 10:43) [2]

Да используй SuperIbEventAlerter. Кто тебе мешает зарегистрировать все события сразу? Под IBX, FIB+ глюков не замечено. Под BDE есть неприятный глюк вызывающий довольно длительное зависание приложения при отсоединения клиента от базы. Но как я разобрался глюк связан с проблемами самого BDE. Вызов уходит в BDE и зависает там. А так работает замечательно.

Изобретать велосипед не стоит. Есть куча самописанных алертеров.

А по поводу UDF Александр прав. Для своего метода видимо подойдет такой способ. Создаешь таблицу которая содержит например идентификаторы всех событий и количество возникновений событий. Клиентское приложение регулярно - например раз в пять сек. считывает эту таблицу. смотрит какие поля изменились и формирует внутреннее событие. Ну а тригера и процедуры базы инкрементируют определенные записи таблицы событий. Вот и все завязано под commit.

Удачи!

← →
int64 © (2002-05-24 12:00) [3]

Огромное спасибо.
Я то и спрашивал, чтобы не изобретать велосипедов.

Вот ещё что, черт с ними с алертерами, тут просто ситуация: если UDF без commit"а идут, можно как-нить их под commit запустить. Хоть через з....цу.

И, пожалуйста, уточните на счёт:
> только udf будут срабатывать сразу, а не после commit, как
> events

тут разночтение по поводу events.

← →
Alexandr © (2002-05-24 12:10) [4]

через задницу можно, но не UDF.
1) Сделать служебную таблицу, в которую события писать.
2) Отдельное приложение/сервис периодически лезет в эту таблицу, читает новые события и рассылает их своим способом клиентам

← →
int64 © (2002-05-24 12:37) [5]

С событиями всё понятно, я уже забыл за них.
Интересуюсь:
Как UDF под commit запустить. Не в конкретном случае, а впринципе в каком-нибудь варианте возможно?

← →
Alexandr © (2002-05-24 13:05) [6]

никак.
UDF вне контекста транзакции так же как генераторы и внешние таблицы.

P.S. как ты себе представляешь откат работы UDF?

← →
int64 © (2002-05-24 13:16) [7]

Данные из UDF ничего не делают, а выходят из базы наружу. И там ждут commit. Так можно?

Только как этот commit поймать? И боюсь они десяь раз обновятся до подтверждения.

← →
Alexandr © (2002-05-24 13:19) [8]

че это за "данные из UDF" и где они "ничего не делают", и как это они "выходят наружу" и где это они "ждут commit"
Подумай на трезвую голову об ответах на эти вопросы

← →
int64 © (2002-05-24 13:28) [9]

Имеется около 20 таблиц. В каждой около 100 записей. Записи быстро модифицируются; новые не добавляются. Нужен какой-угодно, но оперативный мониторинг.
Как его ещё сделать?

← →
Alexandr © (2002-05-24 13:30) [10]

ты уверен, что для этого тебе база данных нужна?

← →
int64 © (2002-05-24 13:42) [11]

Да. Именно база. Эти 20 таблиц только часть её. И данные поступают только с клиентов. Ещё внутри немного перевариваются, чтобы распихаться по таблицам.

Хочу снимать показания базы через UDF.

Почему бы просто циклически (раз в 5 секунд) с клиента не опрашивать эти 20 таблиц, если там так мало записей? Попробуй, может это заработает быстро. А если не заработает быстро, значит у тебя сеть 10 mbit и ее надо менять на 100 mbit. Иногда лучше не мудрить с программированием, а улучшить железо.
Если, конечно, речь идет просто о мониторинге...

kaif © (24.05.02 14:13)

Я не могу позволить себе терять обновления в записях. Сами старые записи не нужны. В БД нужно хранить только последние. Так же надо иметь историю всех записей со всех таблиц в виде некоторого представления (напимер суммы). Реализовать такую "сумму" в БД нельзя. Поэтому нужно перехватывать малейшие изменения.
Я уже могу получить устаревшие данные когда опрашиваю БД по post_event. А тем более по таймеру.

А ты через тригеры сделай и записывай все изменения куда нибудь, как например в IBExpert сделан лог

2 Pavel_S © (25.05.02 16:17)

> записывай все изменения куда нибудь

Ну надо же. А я чего пытаюсь добиться у аудитории?

Подвожу резюме выше сказанного.

1. Инициировать запросы с клиента ("не изменилась ли какая запись?"). По таймеру или евенту.
Клиент может тормозить и пропускать обновления.

2. Извратить UDF, добавив в неё сокет на левую программу. Распихать UDF"ы по триггерам.
UDF будет отсылать не подтверждённые данные.

Есть ещё варианты? Не стесняйтесь предлагайте.

Конечно же ещё вариант, просматриваемый у younghacker и Alexandr.

3. Ввести служебные таблици для каждой таблицы (журналы изменений). Толстый клиент (по таймеру или событиям) просматривает журналы на предмет новых записей и удаляет старые.

Тогда не будут теряться апдейты, но система, и без того не реалтайм, потеряет много в своей оперативности.

Такой вариант подойдёт для не "интенсивных" систем. Проводок документов, например. В моей же области журналы быдут только пухнуть.

К тому же хотелось бы "вести моноторинг" на всех клиентах.

Альтернатива post_event. Найти похожие ветки