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

Какие я знаю варианты работы с логической единицей документ:
1. Сохранять данные в базу при любом изменении в документе и заново перезапрашивать документ целиком. Тогда пользователь всегда будет видеть последнюю версию документа и в какой-то степени может быть уверен, что его изменения так же увидят и примут к сведению. Минус в этом способе достаточно большой - может быть нарушена логическая целостность документа.
2. По завершении работы с документом выполняется короткая блокировка таблиц и документ перекрывает данные, которые на данный момент лежат в базе. Минус в подходе: "Кто последний, тот и папа". Если два пользователя работали с документом одновременно, то гораздо обиднее будет тому пользователю, который первым закрыл документ.
3. Использовать длинные блокировки. То бишь, кто первый открыл документ, тот его блокирует, а остальные могут сосать лапу (ReadOnly, например). Минусы подхода - не знаю, как это красиво реализовать на Pg

SELECT ... FOR UPDATE меня не устраивает в принципе. Хотя, по номеру транзакции в cMin я могу получить, кем запись заблокирована на данный момент, тем не менее, я не могу сказать COMMIT или ROLLBACK для этой транзакции если у меня другой PID. Это как раз ситуация, когда клиент, блокировавший записи вдруг отвалился. А еще хуже будет, если процедура не проверит запись на заблокированность и попробует писать в нее. Тогда у меня будет болтаться куча клиентов, ожидающих завершения первой транзакции.
Больше всего в данном случае меня бы устроил механизм семафора, причем если умирает PID, породивший семафор, семафор так же бы умирал. Так же неплохо бы прибивать такой семафор с другого PID'а, например под админом.
Может есть другие решения?

mwolfЖурнал работы с документами завести

Согласен. Журнал поможет во многих случаях, не только в этом. Правда есть одно но. Желательный эффект: Пользователь открывает документ на редактирование; ему сообщают, что документ уже открыт; пользователь получает документ на чтение. С Журналом все красиво работает, пока юзер не отвалился от базы с открытым документом, забыв сообщить базе, что он больше документ не держит. Как в таких случаях быть?

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

А кто у нас разработчик? Что значит "не проверит"? Значит ошибка в программе.
Просто система развивается "на коленке", бишь этап активной эксплуатации системы продолжается параллельно с этапом разработки. С учетом штата разработчиков, я не могу гарантировать, что какой-нибудь "атавизм" не будет писать без проверки.

J-ProНарод, у меня похожий вопрос. Только в моём случае у меня около 30-ти различных связанных между собой таблиц, много хранимых процедур и т.д. А сейчас меня попросили сделать так, чтобы два пользователя одновременно не могли апдейтить одну и ту же запись, потому что по их словам: "БД может полететь или вся система". В принципе, от одновременного создания ничего не будет? И от доступа тоже, ведь так? Мне важно предотвратить эффект именно от одновременного апдейта одной ти той же записи.


Отвечаю я. Потому что сам хочу поразбираться с этим вопросом. Гляди. Основной принцип корректировки данных это:
1. SELECT
2. <<DO SOMETHING>>
3. UPDATE ([INSERT], [DELETE])

Теперь рассмотрим как разнесены 1-ый и 3-ий элементы во времени.
I. В одной транзакции. Тогда пофиг, что делают другие пользователи - в PgSQL мы работаем со слепком базы на момент транзакции, поэтому не изменятся ни данные на момент селекта, и не будет повреждена целостность базы на момент update'а
Пример:
BEGIN ;
INSERT INTO t1 (val1, val2) (SELECT val1, val2 FROM t2) ;
COMMIT ;

II. В двух транзакциях с "коротким" промежутком между ними. Например, работа робота. В таком разе состояние базы может измениться между транзакциями. Если мы работаем с кучей записей, может оказаться, что часть записей отмодифицирована нами, часть записей другим пользователем. Тогда, если остальные пользователи могут подождать пока робот наработается, можно просто заблокировать все выбранные нами записи "SELECT ... FOR UPDATE". Или даже залочить нужные нам таблички.

III. Все так же как во втором случае, но работает пользователь. Пользователь делает SELECT, долго тупо глядит на результаты SELECT'а, затем правит пару циферок или буковок и делает UPDATE. Естественно, простая залочка записей нам не поможет. Потому что пока пользователь "долго тупо смотрит..." другие ждут выполнения приторможенного UPDATE'a этой же записи (если нажали на кнопку "сохранить" чуть пораньше.

Насчет пункта III есть такая идея. Создаем табличку CREATE TABLE "Tab" ("UPid" PID, "uName" NAME, "Record" OID). Табличка содержит PID процесса пользоватиля, взявшего запись, имя пользователя и указатель на запись (Record::Oid). До захвата записи пользователь запускает функцию, которая выполняет следующий функционал:
1. Проверяет в табличке те PID'ы с теми пользователями, которых сейчас нет в системе. И прибивает отвалившихся пользователей.
2. Проверяет нет ли в табличке кого-нибудь, кто держал бы нужную нам запись. Если кто-то есть, поднимает Exception или еще как ругается.
3. Если запись никем не заблокирована, создает новую строчку в этой табличке куда запишет ID процесса, ID пользователя и ID строки, таблицы или логического объекта (уже от вкуса программиста зависит).
4. Возвращает клиенту флажок типа все в порядке.
Тока надо не забывать прибивать залочки, когда пользователь закрыл документ.

И еще фишка. Пользователь может некорректно закрыть документ, так что процедура удаления залочки не отработает. При этом, коннект может остаться в живых (для Shared коннекшнов это нормально). Тогда чтоб распинать документ надо будет ручками почистить табличку, или выгнать этого пользователя из программы в принципе. Ж;))

J-ProУважаемый Kruchinin Pahan !

1. Что можно сделать, чтобы предотвратить сбой БД при одновременной попытке двух пользователей проапдейтить одинаковую запись в базе? И вообще, нужно ли это при таком подходе? Или же PostgreSQL не полетит, а как-то разберётся с этим сама, своим механизмом?


На самом деле, никакого "сбоя" БД в PG быть не должно. Все дело в конкурентных транзакциях. Смысл в том, что ПГ хранит все версии одной и той же строки в БД (до VACUUM). Когда ты делаешь SELECT ты выбираешь текущую версию, даже если уже существует более поздняя версия этой строки, от другого пользователя, но транзакция этого пользователя еще не завершилась. Когда ты делаешь UPDATE, создается копия текущей (на момент этой транзакции) строки с соответствующей заменой значений, указанных в запросе. Даже если кто-то делает update одновременно, сама БД отреагирует на это нормально. Правда, в конце концов в базе данных останется видимой запись со старшим номером транзакции.
Вобщем, смысл в том, что сколько бы ты ни update'ил запись, физическая целостность БД при этом не пострадает и ничто не полетит.
Другой вопрос в том, что для пользователя более важной является логическая целостность.

Предположим есть кладовщик и менеджер продаж, которые одновременно открыли одну и ту же накладную. Менеджера клиенты попросили заменить в накладной болт М6 на гайку с резьбой. А кладовщик в это же время проставляет партии товара. Документ сделал SELECT и обоим показывается болт М6. Кладовщик ставит партию болт1М6, а менеджер меняет болт на гайку. По закрытии документа проходит два UPDAT'а. Все рады, пока не откроют документ по новой. Оказывается, что мы продали гайку из партии болтов М6. Это на самом деле большая проблема, использует ли база данных метод конкурентных транзакций (PgSQL) или метод блокировок таблиц (MsSQL) - без разницы.

J-Pro
2. Не надо ли ничего предусматривать на тот случай, если два пользователя вызовут одну и ту же хранимую процедуру ВЫБОРКИ? Или тут полегче и моно всё оставить, как есть?

На самом деле любой БД пофиг что делают пользователи. Тем или другим способом такие вещи регулируются. Например, я делаю SELECT, пока он выполняется, другой пользователь делает INSERT. В MsSQL транзакция на INSERT будет приторможена, пока не выполнится моя транзакция на SELECT. В PG транзакция на INSERT успешно завершится, но результаты будут мне не видны, потому что транзакция на INSERT имеет старший по отношению к моей номер и добавленная строчка находится в будущем по отношению к моей транзакции.