powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird + fbExpress lock conflict
4 сообщений из 204, страница 9 из 9
Firebird + fbExpress lock conflict
    #40115178
YuRock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GJ
Либо я не понял тебя, либо ты не понял меня.
В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт.

Это достигается путём открытия еще одной транзакции, перед редактированием документа. И коммитом этой транзакции.
Если забыть ее закоммитить - считай, что в ту таблицу ничего не добавляется, другие пользователи эту блокировку не увидят, и получим твою ситуацию - одновременное обновление документа.
Эта только одна из возможностей.
Вторая (я уже писал, но ты как будто не читал) - если "другое приложение" запущено под тем же пользователем, то оно, скорее всего, тоже разрешит обновлять документ (не знаю, как там у тебя, но обычно делается так, чтобы вообще хоть кто-то мог его доредактировать в случае сбоя). И тогда опять получаем твою ситуацию - возможность одновременного обновления документа.
GJ
Таблица с содержательными данными при этом не блокируется
Это имеет значение, но этого не достаточно.
GJ
поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет.
Имеет непосредственное, как видишь.
...
Рейтинг: 0 / 0
Firebird + fbExpress lock conflict
    #40115341
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
YuRock

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:


Да, действительно фигня какая-то. Я до конца не дочитал, подумал что это про классическую отдельную таблицу 1:1 для конфликтов без порождения версий содержательной записи.
...
Рейтинг: 0 / 0
Firebird + fbExpress lock conflict
    #40115378
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишка
YuRock

А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то:


Да, действительно фигня какая-то. Я до конца не дочитал, подумал что это про классическую отдельную таблицу 1:1 для конфликтов без порождения версий содержательной записи.


Ещё подумал. Могу предположить только, что там схема такая:
1. При создании записи в основной таблице триггер порождает сателлита ID-USER-TAIMSTAMP c null в артибутах. Ни основная запись, ни сателлитная никому не видны до завершения транзакции и на первичной вставке никто не влезет.
2. При редактировании сначала стартуется служебная транзакция, в которой выполняется нечто вроде его LockRecord, только select для выдачи сообщения выполняется по if RowsAffected=0 и сомнительный в смысле работы под одним аккаунтом с нескольких точек if LockUser<>USER там не нужен. Служебная транзакция коммитится, чтобы вывеска "Занято Васей Пупкиным" была видна всем поступающим аналогично, в случае успеха стартуется основная и поехали. Сбрасываются атрибуты сателлитной записи в основной транзакции перед её завершением.

Но.

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

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

В-третьих, если объект чуть сложнее палки и верёвки, доступ ко всем элементам его состава/составов (детализация возможна по нескольким критериям) должен осуществляться строго по этой схеме через заголовок, в том числе из триггеров других таблиц и всяких хранимок. Что, как сказал один мудрец, is the road to hell Это относится не только к этой схеме, а к пессимистическим блокировкам в принципе, смысл применения которых сильно зависит от массы причин. It, как говорится, depends.
...
Рейтинг: 0 / 0
Firebird + fbExpress lock conflict
    #40115503
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Старый плюшевый мишка
Во-вторых, в случае падения приложения, окончания току в розетке компа юзера, взмаха швабры уборщицы по проводам в хабе и тэ пэ в сателлитной таблице остаются мусорные записи, которые не дадут добраться до документа никому, в том числе и этому юзеру после перезахода.
Триггер на дисконнект вполне решает все означенные проблемы. Но есть падения сервера... они очень сильно реже (серверные упсы обычно получше десктопных) и таки потребуют вмешательства админа.
...
Рейтинг: 0 / 0
4 сообщений из 204, страница 9 из 9
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird + fbExpress lock conflict
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]