как правильно выполн."по таймеру" действия в бд (клиент-сервер) ?

← →
ari_9 (2007-10-15 23:42) [0]

Firebird / Firebird Embeded

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

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

приходят в голову такие варианты

1. выбирать "ведущее" клиентское приложение, которое будет инициировать действия с бд (запускать sp). проблема - если приложение потеряло связь с бд, на "перевыборы" может уйти время большее, чем допустимо по бизнес логике на промежуток между запусками sp

2. все клиентские приложения по своим таймерам инициируют действия, но средствами FB происходит "отсечение" тех, которые поступают до истечения требуемого периода после окончания предыдущего действия .... как это реализовать ? ну, допустим, некоторая рабочая таблица, куда эта sp пишет текущее время сервера ("now") и полученное значение генератора .... но ведь эта же sp, запущенная другим клиентским приложением будет в иной транзакции и может "не успеть" увидеть эти данные в рабочей таблице и стартовать параллельно ... единственное, что независимо от транзакций, это генераторы, но как к ним привязать время ?

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

господа, я понимаю что вопрос почти ламерский. но ничего в голову не приходит и гугл как-то слабо помог

← →
DrPass © (2007-10-16 01:32) [1]

> 1. выбирать "ведущее" клиентское приложение, которое будет
> инициировать действия с бд

> 2. все клиентские приложения по своим таймерам инициируют
> действия, но средствами FB происходит "отсечение" тех, которые
> поступают до истечения требуемого периода после окончания
> предыдущего действия

Знаешь, что такое KISS-принцип программирования? Расшифровывается "Keep it simple, stupid!" Не извращайся, сделай отдельную небольшую программу (лучше сервис), которая будет висеть на сервере и периодически делать с базой то, что тебе надо.

← →
Сергей М. © (2007-10-16 08:19) [2]

> Firebird Embeded

В связи с этим особо радует упоминание именно Embeded.

← →
Sergey13 © (2007-10-16 08:34) [3]

> [0] ari_9 (15.10.07 23:42)

Ты не написал самого главного - зачем все это нужно?
И почему все проверки и изменения не повесить на констрейнты и/или тригеры, которые как раз и предназначены для этого.

← →
ari_9 (2007-10-16 09:30) [4]

DrPass

да, я думал над этим вариантом. если ничего лучше не придумаю, так и будет. два очевидных недостатка. 1. если этот процесс на сервере слетит - работа клиентов бессмысленна (при этом еще нужно через бд делать какой-то вариант сигнализации об этом). а в моем варианте хотя бы один работающий обеспечивает себя актуальной бд. 2. я на delphi пишу, клиенты предполагаются точно на win, а собственно бд черт знает где лежать будет

Сергей М.

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

понятно, что в случае Firebird Embeded и один пользователь можно без всяких проверок по таймеру клиенсткого приложения пускать sp

Sergey13

есть некий набор данных. данные падают от клиентских приложений. для приложения это "запостил и забыл". бд (в реальности, конечно, на сама бд, а по стороннему запросу) должна обрабатывать эти строки в зависимости от того, сколько времени прошло с их поступления. то есть грубо говоря, получили набор данных, через Х минут, если к нему не было запроса определенного типа, изменили его состояние (значение нескольких полей), еще через Y минут снова поменяли, через Z выполнили проверку, если некое условие выполнилось, снова поменяли состояние, при другом условии удалили

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

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

сейчас оно все работает с большим количеством пользователей в варианте однопользовательского клиента - то есть инициируются действия в бд без каких либо проверок и логики

← →
Сергей М. © (2007-10-16 09:44) [5]

> ari_9 (16.10.07 09:30) [4]

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

← →
Sergey13 © (2007-10-16 09:52) [6]

> [4] ari_9 (16.10.07 09:30)

Не покидает меня смутное ощущение, что ты используешь какие то а-ля временные таблицы и пытаешься таким образом, "подчищать хвосты". Я прав?

← →
Маша Шрайбер © (2007-10-16 10:14) [7]

А у меня ощущение, что действительно временные таблицы. что означает, что что-то не так в консерватории.

← →
Desdechado © (2007-10-16 11:07) [8]

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

← →
ari_9 (2007-10-16 13:44) [9]

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

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

на данный момент задача сузилась до следующего

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

1. записали что-то во временную таблицу, получили значение генератора etc, вообще что угодно сделали

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

3. собственно выполнили эффективный код - требуемые действия в бд

4. аналогично 1, записали что-то во временную таблицу, получили значение генератора etc

так возможно сделать ? пункт два вызывает сомнения. может ли сп каким-либо образом анализировать запуск себя же в других транзакциях ?

← →
Sergey13 © (2007-10-16 13:54) [10]

> [9] ari_9 (16.10.07 13:44)
> господа, никаких "грязных" данных. наоборот, это "живые" данные
А не хочешь просто написать какова предметная область программы и что предполагается иметь от реализации сего алгоритма.
Это не праздное любопытство.

← →
ari_9 (2007-10-16 13:54) [11]

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

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

а теперь бяка. у нас есть некоторое граничное число заданий в пуле, начиная с которого, скорость понижения статуса заданий меняется. то есть, допустим, задание "теряет статус" со скоростью 0.1 в минуту, если текущее число "неразобранных" заданий того же статуса до 50, 0.05, если до 200 и статусы "замораживаются", если в пуле более 200 заданий. это очень упрощенно, но, думаю, идея ясна. нельзя постфактум расчитать текущий статус конкретного задания - нужно периодически пересчитывать его у них всех. при этом временные промежутки выбираются значительно меньше, чем среднее время изменения статуса - то есть даже задержка/пропуск нескольких из них допустим

> такая структура требует приложение-сервер. но у меня уже
> клиент-сервер

У тебя 2-хзвенка: "толстый" клиент + СУБД-сервер
Я же тебе говорю о 3-хзвенке: "тонкий" клиент + AppServer + СУБД-сервер.

Выделенной жирным звено как раз им должно заниматься тем, о чем ты ведешь речь.

← →
ari_9 (2007-10-16 15:33) [13]

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

← →
ari_9 (2007-10-16 15:33) [14]

> [11] ari_9 (16.10.07 13:54)
Ну, тогда я думаю, что
> [1] DrPass © (16.10.07 01:32)
это то, что надо.

ЗЫ: неужели нормальное объяснение для чего это все надо такая тайна.

> сейчас все переделать достаточно затратно

Мож и не так затратно.. Смотря что там, в клиентском проекте, понахреноверчено, какие компоненты доступа используются и как ..

как правильно выполн."по таймеру" действия в бд (клиент-сервер) ? Найти похожие ветки