Есть большая глобаль вида
^V(код объекта, код параметра, время)=значение.
В нее постоянно сыплются данные и из нее формируются отчеты.
Ввод данных идет по нескольку строк (4 и больше) в одной транзакции - исходный показатель плюс пересчет производных(зависимых) показателей.
Отчеты содержат по несколько сотен показателей на определенное время.

Насколько я понимаю, мне придется использовать для отчетов разделяемую блокировку вроде
lock ^V#"S":10
а для записи эксклюзивную вроде
lock ^V:10

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

С другой стороны, если блокировать каждый показатель в отдельности
lock +^V(код объекта, код параметра, время)
по мере обращения к ним при вводе и при формировании отчета, я непременно нарвусь на дедлок.

Как решаете такие проблемы, коллеги?

Блок А.Н., krvsa
...я так понимаю, у вас значения старых данных сохраняются в истории, а изменения идут путем дозаписи новых величин не изменяя старые?

Нет, время это вполне конкретное, либо граница суток, либо 2-х часов, и изменение значения показателя на это время заменяет предыдущее.
Я думал насчет использования дополнительного индекса, назовем его N, который содержал бы порядковый номер обращения к глобали, неважно, на запись или чтение. Тогда можно было бы выбирать в отчет записи, у которых N меньше, чем N запроса. В этом случае можно вообще не блокировать глобаль.
Смущает меня то, что производные показатели верхнего уровня (по цеху, предприятию) зависят от тысяч исходных показателей на технологических объектах, т.е. пересчитываются при вводе каждого i-го исходного показателя. Они будут иметь тысячи версий значений по N(i).
Выигрываем в отсутствии блокировок, проигрываем в увеличении размера базы, некотором усложнении программы.
Каждые 2 часа приходит 2-3 тысячи исходных значений, половина с телемеханики, вторая половина ручной ввод. Рассчитывается до 1тыс производных показателей, 90% которых имеет 2-5 исходных, 10% - от 100 до 2000. Двухчасовые сводки смотрят до 30 пользователей, суточные сводки поутру смотрят примерно 100 пользователей.
Считаете есть смысл вводить версионность значений, чтобы уйти от блокировок?

kolesov
...структура хранения дефолтная, записывается единовременно от 1 до 30 объектов.

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

Блок А.Н.,

Спасибо, беру таймоут, надо обмозговать это дело.
Попробую вариант 2 как самый простой.
Почитаю про версионность.

Ptn,

Ваше предложение, особенно в части анализа завершенности транзакций, напоминает версионность данных в базе, как она описана по ссылке:
http://www.ibase.ru/devinfo/versions.htm
Дата и время в моей таблице
^V(код объекта, код параметра, время)=значение
это не время сохранения значения в базе, а время замера. Например, значение параметра на 14 часов может прийти в 14ч15мин. А может диспетчер ввести его в конце смены.
Мне нравится идея версионности, но делать на прикладном уровне то, что в Oracle или InterBase встроено в систему... Но не исключено, что попробую.

=Dimon=

Вы похоже на прикладном уровне реализуете транзакции? Поле deleteFlag видимо сбрасывается в 0 после того, как вся порция записана в таблицу?
Здесь выше kolesov пишет, что это излишне, если Вы работаете через объекты и SQL.
Спасибо, интересный пример и временные характеристики тоже.