Уф, чтобы не повторяться, для начала почитайте мое описание создания собственных кэшэй входящей и расчетной информации. Все что там описано про кэша, более менее позволяет снизить нагрузки на расчеты и получение сложной структуры информации. Про монопольные блокировки внимания не обращайте, я потом сделал более универсальный механизм.\r
\r
С блокировками я примерно поступаю точно так же, как и Вы, только что у меня в кэшах есть такое понятие - состояние расчета (кто посчитан/кто не посчитан). Соответствующе при начала расчета я в этой таблице блокирую оператором UPDATE записи всех, кто затребован к расчету, считаю тех, кто не посчитан, а потом снимаю блокировку. Соответствующе если на момент расчета все затребованные расчитаны, то процедура просто выходит и ничего не делает. Теперь рассматриваем ситуацию, когда хранимую процедуру расчета вызывает другая сессия:\r
Сначала выполняется проверка о необходимости расчета и если ее нет, процедура просто выходит. Если считать есть что, то вариантов дальнейшего поведения может быть 2:\r
1. Если она должна посчитать тех, кто в данный момент не рассчитывается, то она их и считает\r
2. Если затрагивается часть договоров, которые в данный момент рассчитываются другой сессией, то ХП по опции BLOCKING ON приостанавливает свое действие до окончания расчета другой сессии и далее считает всех, кто еще не посчитан. Кстати если первый запущенный расчет посчитает всех, кто затребован во втором запущеном расчете, то он соотвествующе получается после того как отработает первый просто выйдет, так как считать уже и нечего :)\r
\r
P.S. Поясню заодно, почему я блокирую всех, кто затребован к расчету, хотя по идее бы казалось более логичным заблокировать только тех, кого действительно необходимо посчитать:\r
дело в том, что расчет вызывается не просто так - на основе результата его вычислений потом строяться отчеты, формы и т.д. Различных видов данных, получающихся в результате расчета много. Плюс по входящим табличкам-кэшам частенько в денормализованном виде разложена информация, с которой базировался расчет. Соотвествующе любой код, вызвавший ХП и указавший ей затребованные к расчету договора вправе ожидать, что во время расчета пользователь не сможет изменить входящие данные, что приведет к их очистке из входящих и расчетных кэшей.\r
\r
Немного сумбурно все обьяснил, но думаю принцип наверное понятен. Думаю со временем свои решения буду в рассылку по ASA ложить, все равно все эти решения на ней разрабатывались.

авторКажется понятно. Но в первую очередь хочу отметить различие в наших задачах - вы как я понял накапливаете инофрмацию, а потом запускается процедура расчета неких ведомых таблиц, которые укладываются на хранение? Нечто вроде самодельного кэша?
Угу, так и есть. Проект - расчет зп, входящих данных и алгоритмов расчетов уйма, делать он-лайн расчет при изменении любого параметра сотрудника смысла нет. Плюс есть такое понятия как текущий расчетный месяц и фактически вся информация может изменяться задними числами. Поэтому в кэшах в пределах расчетного и сторнируемых месяцов аккумулируется по полочкам разложенная информация, которая используется при расчетах и отчетах. Далее при переходе на следующий расчетный месяц необходимая расчитанная информация переноситься в архивы, кэша затираются и начинается новый этап работ по сбору информации от пользователей и выполнению расчетных операций по мере их востребования. Фактически расчет неявно вызывается при любом обращении пользователя к расчетной информации текущего или сторнируемых месяцов - будь то просмотр с клиента лицевого счета или выдача ведомостей. При обращении пользователя к архивной информации она просто береться с архивов и естественно никаких расчетов не производиться. По мере обрастания кэшей информацией скорость отклика системы существенно увеличивается - ведь теперь ей надо просчитывать только тех, кто еще не просчитан или же тех, у кого после расчетов были новые изменения входящей информации. Как пример: распечатанная на 1000 сотрудников ведомость при пустых кэшах вызывает процедуру расчета начислений/удержаний и налогов, которая выполняется 9 секунд. Далее в ходе работы была изменена информация по 50 сотрудникам. Новое построение ведомости вызовет расчет, который пересчитает 50 сотрудников, что составит примерно 40 мс. В случае же если ничего по сотрудникам не было изменено, то расчет прервется и будет затрачено время только на построение отчета.

Кстати модель я эту изначально разрабатывал на MSSQL, но потом БД перевел в ASA. Забавно получилось, что если почитать в BOL работу оптимизатора ASA и его кэширования страниц и планов запросов, то получается, что я на уровне бизнес-логики проекта смоделировал идейно похожую схему работы ASA. Честно говоря сам был удивлен, насколько похоже у меня с iAnywhere все получилось :)

Естественно такая система подходит, если ведется работа с определенным и не большим обьемом информации за конкретный промежуток времени. Для случаев, когда отчет рассчитывается и строиться по огромному массиву данных, причем со сложными условиями такой подход не допустим. Хотя в принципе другие подходы есть:
1. Если есть понятие периодов, на которые храниться некая рассчитываемая информация и эта информация не часто изменяется, то вполне можно спроектировать модель хранения отклонения информации, когда в БД храниться только точки изменения информации. Наглядный пример - это расчет коммунальной платы, где входящие данные (тарифы, услуги, жильцы, льготы) изменяются достаточно редко и у малой части от общего обьема. Соотвествующе не имеет смысла хранить каждый месяц начисления для каждого лицевого счета, а хранить результат расчета только при изменении входящих данных. В итоге экономим на размере таблиц и БД, что увеличивает скорость обработки информации и снижает стоимость сопровождения такой БД
2. Иногда полезно вместо низкоуровневых блокировок СУБД использовать собственный механизм блокировок. На ASA он реализуется на удивление легко - всегда можно сделать табличку, в которой по сессиям регистрируются заблокированные логические обьекты и навесить по триггерам входящей информации проверки на существование блокировок этих обьектов. Получается прямая выгода - так как если кол-во таблиц входящей информации велико и проводимые по ним операции тянуться долго, то с одной стороны мы должны блокировать все обрабатываемые данных всех таблиц, с другой стороны вся эта информация может быть логически сгруппирована в более высокоуровневые для нас обьекты блокировки (например есть логическое понятие Договор, на которое существует не один десяток таблиц с описанием его возможных значений и атрибутов в различных разрезах и периодах). В случае физической блокировки нам придеться блокировать все такие таблицы, что приведет к дополнительным накладным расходам и времени для блокировки всех необходимых к расчетам записей. В случае же логической блокировки нам будет достаточно занести в таблицу блокировок необходимый список договоров, таким образом реально просто выставляя флаги для триггеров с целью запрета изменения любой информации по этим договорам (это еще можно назвать собственной версией реализации экскалации блокировок - то есть их обьединения на более высокий уровень). В принципе на ASA все это прекрасно делается, кстати через событие Disconnect прекрасно решается проблема отвала сессии, в которую можно поставить автоматическую чистку блокировок по ID сессии. В принципе со временем я и это планирую выложить в рассылке по ASA, так как с одной стороны тема достаточно интересная, а с другой ASA просто идеально подходит для организации таких "хитрых" решений.