|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
GJ Либо я не понял тебя, либо ты не понял меня. В БД существует специальная таблица, в которую заносится информация о том, что такой-то пользователь "открыл на редактирование такой-то документ" (в кавычках, потому что это условно-упрощенно, чтобы не вдаваться в детали). Соответственно, другое приложение не позволит открыть документ на редактирование, если он уже кем-то открыт. Это достигается путём открытия еще одной транзакции, перед редактированием документа. И коммитом этой транзакции. Если забыть ее закоммитить - считай, что в ту таблицу ничего не добавляется, другие пользователи эту блокировку не увидят, и получим твою ситуацию - одновременное обновление документа. Эта только одна из возможностей. Вторая (я уже писал, но ты как будто не читал) - если "другое приложение" запущено под тем же пользователем, то оно, скорее всего, тоже разрешит обновлять документ (не знаю, как там у тебя, но обычно делается так, чтобы вообще хоть кто-то мог его доредактировать в случае сбоя). И тогда опять получаем твою ситуацию - возможность одновременного обновления документа. GJ Таблица с содержательными данными при этом не блокируется GJ поэтому и говорю, что к обсуждаемому вопросу это отношения не имеет. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 11:53 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
YuRock А вот тут якобы есть (вариант 2), но написано странно, сырой материал какой-то: Да, действительно фигня какая-то. Я до конца не дочитал, подумал что это про классическую отдельную таблицу 1:1 для конфликтов без порождения версий содержательной записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2021, 18:15 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка 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. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2021, 00:17 |
|
Firebird + fbExpress lock conflict
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Во-вторых, в случае падения приложения, окончания току в розетке компа юзера, взмаха швабры уборщицы по проводам в хабе и тэ пэ в сателлитной таблице остаются мусорные записи, которые не дадут добраться до документа никому, в том числе и этому юзеру после перезахода. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2021, 14:00 |
|
|
start [/forum/topic.php?fid=40&startmsg=40115178&tid=1559880]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 137ms |
0 / 0 |