Ibase Events вопрос другой

← →
LLineser (2005-01-26 14:37) [0]

Здравствуйте !
Вот такие вопросы:
имеем - сервер к которому подключено n клиентов. Клиенты кладут что-то в базу и устраивают алерт серверу. Сервер выполняет нужные действия и возвращает в ту запись которую создал клиент ответ и устраивает алерт клиенту. Вроде как обмен получается.

1) Вопрос, логично ли так делать и можно ли вообще сделать именно так ?

2)когда приходит алерт сервер знает лишь что таблица обновилась, но не знает конкретный номер записи в этой таблице, верно ?

3) Если разные клиенты производят одинаковые алерты то сервер получит лишь один, но со значением числа произощедших алертов ?

← →
Sergey13 © (2005-01-26 14:41) [1]

А если не так мудрено, без алертов, что надо то?
Например переведи
>и возвращает в ту запись которую создал клиент ответ
Может тебе тригер нужен?

← →
LLineser (2005-01-26 14:53) [2]

Я объясню почему я хочу так:
1) получается автоматическое логирование и запросов с клиента и ответов с сервера прито в одной записи (видно что спросил и что ему ответили)
2) время ответа от сервера до 3-ех минут (сервер - модемный пул)

← →
Sergey13 © (2005-01-26 14:58) [3]

Ну дык в тригере и заполняй нужные поля. Или я не понимаю о чем речь.

← →
Johnmen © (2005-01-26 15:10) [4]

>LLineser (26.01.05 14:53) [2]

1) Логирование не так делается. Запросы чтения не залогируешь.
2) ... ?

Не советую пользовать без КРАЙНЕЙ нужды евенталертер. И эта нужда должна быть такая, что по-другому никак...

← →
Digitman © (2005-01-26 15:37) [5]

> LLineser

смотри
> Johnmen © (26.01.05 15:10) [4]

без крайней нужды не трогай айби-ивенты.

протоколирование же изменений в БД вполне обходится безо всяких Event-премудростей, прямо на стороне сервера, средствами триггеров

← →
LLineser (2005-01-26 15:47) [6]

Запросы на чтение ? Я имел в виду что клиент положил запись в базу и известил сервер об этом. потом сервер обновил запись вписав ответ в нужное поле, и известил клиента.

Вообще суть задачи такова:
Есть модемный сервер. Есть удаленные клиенты. Как механизм обмена я сначала хотел использовать сокеты, но потом решил что в оснве будет лежать БД и с её помощью все будет обрабатываться. Диспетчер нажимает кнопку - сервер должен узнать об этом и начать действия (использовать свободный модем) или известить что все модемы заняты.
Как бы получше это реализовать ? Просто я events alertы вообще никогда не использовал, не знаю их надежноть, достоинства...

← →
Digitman © (2005-01-26 15:52) [7]

о боже..

← →
Sergey13 © (2005-01-26 15:55) [8]

2[6] LLineser (26.01.05 15:47)
>Я имел в виду что клиент положил запись в базу и известил сервер об этом.
Если он уже "положил запись в базу", то сервер об этом узнает и без тебя.
Тебе по кнопке наверное надо определять есть ли связь с БД, и если есть, то класть запись, если нет - стучаться к БД, и, при неудаче, извещать юзера.

← →
LLineser (2005-01-26 15:57) [9]

Связь между клиентом и сервером самая обычная локалка. Поэтому связь с БД держится всегда. Модемы же контактируют с удаленными устройствами.

← →
LLineser (2005-01-26 15:58) [10]

← →
Sergey13 © (2005-01-26 16:11) [11]

2 [9] LLineser (26.01.05 15:57)
Ну тогда с модемами наверное не сюда, а в отношении БД все таки тригеры надо юзать, а не эвенты.

ЗЫ: И пиши понятнее. "модемный сервер", "между клиентом и сервером самая обычная локалка". Никто ж не видел твоих серверов.

← →
LLineser (2005-01-26 16:45) [12]

глупый вопрос, но что будет происходить в таком случае ? Как известить приложение о том что триггер сработал ?

← →
Sergey13 © (2005-01-26 16:48) [13]

2[12] LLineser (26.01.05 16:45)
> Как известить приложение о том что триггер сработал ?
Обычно разбираются почему он НЕ сработал. 8-)
Не волнуйся, если он правильный - сработает.

← →
LLineser (2005-01-26 16:51) [14]

понял :)
но я не о сработает или нет, а о том как я об этом узнаю в своем дельфевом приложении ?

← →
Johnmen © (2005-01-26 16:56) [15]

>как я об этом узнаю в своем дельфевом приложении ?

Зачем ?

← →
LLineser (2005-01-26 17:17) [16]

я программированием БД не занмался уже очень и очень давно, если честно. И многое подзабыл. Просто я помню тригеры делал что бы id полей заполнять. И вроде как в тригере особо не развернешся. А мне нужно чтобы положил например клиент(приложение) запись на сервер (мой сервис который тоже подключен к БД пишу на Дельфи), сервер это отследил и выполнил действия.

По другому говоря для чтобы отловить Alert есть компонента, а чтобы приложение могло отловить срабатывание тригера в БД что нужно сделать ?

← →
msguns © (2005-01-26 17:26) [17]

>а чтобы приложение могло отловить срабатывание тригера в БД что нужно сделать ?

Что нужно сделать, чтоб "отловить" проглоченный огурец ? А, главное, НАФИГА ?

← →
LLineser (2005-01-26 17:35) [18]

нафига ? Да все очень просто клиент кладет запись в базу, сервис (подключенный к этой базе) узнает что это случилось. Конечно можно переодически смотреть таблицу на наличие необработанных (сделать флаг обработки) записей и производить действия. Но постоянно опрашивать таблицу не хочется. Вот алерты сообщают об изменениях по факту, при том в само приложение. Я не знаю сделать чтобы тригер доставлял эту информацию, ведь он работает в самой БД.

← →
Johnmen © (2005-01-26 17:45) [19]

>сервис (подключенный к этой базе) узнает что это случилось.

Н А Ф И Г А ему это узнавать ?

← →
LLineser (2005-01-26 17:49) [20]

потому что из базы он берет инфу что он должен делать и через базу он её и вернет клиенту.

> переодически смотреть таблицу на наличие
> необработанных

что значит необработанных? и как их нужно обработать?

>потому что из базы он берет инфу что он должен делать и через базу он её и вернет клиенту.

Расшифруй, будь любезен...

ИМХО, чел плохо себе представляет что такое транзакции и как они между собою "разбираются".
Если клиенту А надо как можно оперативнее узнать о том, что клиент Б изменил что-либо в таблице Х, то есть 2 пути:
1. Клиент А через заданный таймаут перечитывает таблицу
2. Клиент Б посредством триггера заносит инфу об изменении в некоторый журнал и завершает транзакцию. Клиент А опять-таки через таймаут перечитывет журнал (с последней записи предыдущего курсора для уменьшения трафика) и узнает об изменении.

Но, главное, я не совсем понимаю, зачем А знать о том, что Б чего-то там изменил и ЧТО КОНКРЕТНО изменил. Ну хоть бы объяснил дуракам (это я о таких непонятливых, как я сам) СУТЬ ПРОБЛЕМЫ, т.е. что за задача-то поставлена. Может, весь этот сыр-бор с отлавливанием и нафиг не нужен ?

← →
LLineser (2005-01-26 18:16) [24]

ок, клиент А (по сути диспетчерская) посылает на клиент Б (коммуникационный сервер с 10-20 модемами) запрос на то что ему нужно получить от устройств с которыми связывается Б. Запрос происходит в виде постинга записи в таблицу, которая из себя представляет журнал работ для клиента Б. Сам клиент Б отлавливает то что клиент А попросил позвонить и сделать определенное действие. Происходит дейстивие (оно может растянуться во времени от 50 - до 1000 минут) после чего клиент Б обновит в таблице задание поле в котором будет дан ответ как действие закончилось. Ответ не однозначный да или нет, а по сути сами данные которые получил клиент Б. Таким образом убиваются 2 зайца:
1) связь между клиентами происходит по средствам БД надежность которых предсказуема
2) получается что обновляемая таблица является полным логом произведенных действий.

Так как действия во времени имеют разную продолжительность то вариант с таймаутами я не рассматривал. Понравился вариант с alertами по причине быстрой доставки о проделанной работе.

Вот так вот в кратце.

Более-менее..
Почему бы не сделать так
Имеется:
1. "Абоненты", т.е. те, с кем собственно обмениваются данные через модемную связь.
2. "Сервер", т.е. тот, кто непосредственно связан с модемами и обслуживает собственно обмен данными с "абонентами" (устройствами).Вся информация обмена попадает в "Журнал обмена", который "видит" и обслуживает только сервер.
3. "Клиенты", т.е. РС, с которых могут посылаться задания "серверу".
4. "Журнал транзакций" - таблица в БД (на сервере), открытая для записи и чтения "клиентами" и куда, собственно, они пишут свои "задания".

Решение:
"Сервер" регулярно обслуживает "абонентов", фиксируя данные в ЖО. Для выполнения новых заданий читает ЖТ и "заморачивает" требуемого абонента. По завершению каждого сеанса обмена с "абонентом" он :
- делает дополнение уже имеющейся записи в ЖО
- по ЖТ ищет записи в ЖО и, если находит, заполняет в первом соответствующие поля "ответа".
Т.е. он НИЧЕГО НЕ ПОСЫЛАЕТ КЛИЕНТАМ.

"Клиент" считывает по требованию (кнопка) или периодически (через таймаут) из ЖТ "свои" записи и анализирует (показывает узеру). Если Узер захочет озадачить "Сервер", то он просто добавляет новую запись, которую "Клиент" тут же посылает в ЖТ и перчитывая ЖТ отображает узеру в списке заданий как невыполненное. При очередной перечитке ЖТ (по кнопке или интервалу), если "Сервер" успеет выполнить это задание, то узер это увидит.

Периодически ЖТ и ЖТ сбрасываются в архивы и чистятся.

← →
LLineser (2005-01-26 18:47) [26]

тут понимаешь еще какая проблема - есть режим в котором Клиент озадачивает сервер не просто на действие с абонентом, а и на открытие "прозрачного" канала связи при котором общаются Абонент(устройство) и Клиент как раз через Сервер. В этом случае задержки при транспортировке должны быть минимальными, поэтому придется ставить высокую частоту опроса таблицы ЖТ. А вот алерты вроде как будут только по факту изменений работать, как в OPC.

ЗЫ Спасибо, за предложенное решение, буду думать :)

А почему?
>>Как механизм обмена я сначала хотел использовать сокеты, но >>потом решил что в оснве будет лежать БД
Механизм сеинхронизации Сервера и Клиента - TserverSocket, TClientSocket - достаточно просто и стабильно.
Когда сервер получает задание он перечитывает БД и создает поток обработки данной записи. Т.к. каждый поток должен иметь свое соединение с БД лучше создать потоки заранее и использовать какие либо средства межпотокового взаимодействия например 2 семафора.

← →
LLineser (2005-01-27 13:42) [28]

Почему не сокеты ? просто должна передоваться достаточно разнообразные данные, реальзовывать не хочется. И вопрос надежности конечно

[24] LLineser (26.01.05 18:16)
>клиент А (по сути диспетчерская) посылает на клиент Б (коммуникационный сервер с 10-20 модемами) запрос на то что ему нужно получить от устройств с которыми связывается Б. Запрос происходит в виде постинга записи в таблицу
А почему не так?
1. А посылает запрос Б напрямую (без БД),
2. А получает от Б ответ
3. А постит в БД результат.
Если на 1-2 облом - вовод узеру "Фига тебе". 2-3 локалка и коллизий быть не должно. А вот если БД инициализирует начало сеанса с Б и обламывается, то... Наверное можно, но ИМХО, хуже.

Ibase Events вопрос другой Найти похожие ветки