Вопросик тут вспых.

При апдейте, натыкающемся на закоммиченную новую версию записи, транзакция получит по лбу:

Допустим, в таблице `t` изначально было вот это:

Если теперь сделать вот так:


- то получаю в session #1

То же самое будет, если session #1 стартанёт транзакцию как NO record_version.
Но при старте этой сессией вот так:
- она при этом сценарии получит по лбу тем же "update conflicts with concurrent update", как если бы стартовала сам апдейт, а не select for update with lock.

Так вот, вопрос: не было бы логичнее выдавать эту же ошибку и при старте в режиме read committed ? Ведь select ... for update with lock - он же не с будуна введён, а для апдейта .

hvladТаблоидВопросик тут вспых.А давай без вспыхов, сам объясни - почему это правильноЭто формально правильно, т.к. select стартовал RC и, когда запись стала ему доступной (при коммите другой трн), то он должен видеть закоммиченные изменения. Вот он и видит f01 = -200.
Однако, select этот (session #1) дёргает запись для изменения .
Когда он её нашёл, в ней было еще id = 2, f01= + 200 - она её именно такой видел.
Когда же он её получил в распоряжение, то там оказалось f01= - 200.

Если он теперь будет перетирать значение f01 чем-то другим (вместо выброса ошибки), то не похоже ли это на синдром LOST UPDATE ?

dimitrон просто не понимает, зачем WITH LOCK в RC тр-ции работает в режиме NO_REC_VERДа, я не понял этого, т.к. начал эксперимент с rc rec_ver.
Ну так объясни мне, плз: почему snapshot, натыкаясь на обновлённую запись, НЕ позволяет произойти lost update и вываливает ошибку (что есть гут, КМК), а RC - запросто.

dimitrВ RC это [ перечитывание изменённых конкурентом данных] возможно, в текущей реализации это позволяет режим NO_REC_VER. Я не понимаю, зачем ты приплетаешь тут lost update, ибо ситуация полностью аналогична как если бы наш селект+апдейт начал выполняться после коммита конкурента, а не до. Точно также имеем перезапись чужих изменений своими. Тебя это не беспокоит? Не хочешь поговорить об этом?Когда селект / апдейт стартует после чужого коммита - какие проблемы, всё ОК. Но когда он стартует *до*, молотит там что-то, а затем доходит до чужой залоченной записи и, дожидаясь её высвобождения, ТИХО перетирает - это для мну культурный шок. Такое только в орацле бывает... :-)

А потому - да, этот Гондурас меня вдруг забеспокоил. Хочу поговорить об этом.

Если начал выполняться некий "долгий стейтмент" в read committed, а затем он дошел до залоченной записи и застрял на ней, то это значит, что сначала он УВИДЕЛ её как подходящую под where-условие, и только затем попытался залочить.
И если далее он её получит в изменённом виде (после commit'a конкурента), ПРОЧИТАТЬ её в новом виде - ради бога, но менять эту строку он не имеет права, это самый натуральный lost update. НЕЗАВИСИМО от того, какой там record_version.

Я провёл тест с этой же табличкой, но для замедления использовал в session #1 запрос: update t set f01=33+0*(select count(*) from rdb$types,rdb$types,rdb$types) (и аналогичный с select for update).

Результат такой:
ВремяКтоДействие и результатT1session #1Стартовал в RC стейтмент select … from tmp where <cond01>. Либо стейтмент update tmp set … where <cond01>. T2session #2update tmp set f01 = <some_new_value> where id = :v_id - и эта запись подпадает под условие <cond01>T3session #1Доходит до записи с id = :v_id, которая подпадает под условие <cond01>, и затыкаетсяT4session #2commit;T5session #1Если стартовал select for update - выдаст новое содержимое записи (независимо от rec_version). Если новая версия перестала попадать под условие <cond01>, то НЕ выдаст эту строку. Если был update , то: 1) при NO REC_VER - ПЕРЕТРЁТ её содержимое (при условии, что новая версия продолжает подпадать под условие <cond01>); 2) при REC_VER - вывалит update conflict

То же самое будет и при этом (действия в T2 & T1 из предыдущего примера поменяны местами):ВремяКтоДействие и результатT1session #2update tmp set f01 = <some_new_value> where id = :v_id T2session #1Стартовал в RC стейтмент select … from tmp where <cond01>. Либо стейтмент update tmp set … where <cond01>. T3session #1Доходит до записи с id = :v_id, которая подпадает под условие <cond01>, и затыкаетсяT4session #2commit;T5session #1Если стартовал select for update - выдаст новое содержимое записи (независимо от rec_version). Если новая версия перестала попадать под условие <cond01>, то НЕ выдаст эту строку. Если был update , то: 1) при NO REC_VER - ПЕРЕТРЁТ её содержимое (при условии, что новая версия продолжает подпадать под условие <cond01>); 2) при REC_VER - вывалит update conflict

dimitrWITH LOCK в первую очередь предназначен для сериализации доступа к общему ресурсу. Если он это сможет обеспечивать с минимумом конфликтов - тем лучше. Но Таблоиду почему-то принципы (читай: теория) вдруг стали важнее практики.Во-во! Именно на сериализации доступа я и получил гемор.
Если есть документ, который надо перевести из статуса "Открыт" в статус "Закрыт", и к нему ломятся два и более аттача, то после успешного выполнения select for update в каждом аттаче надо еще раз проеверять содержимое поля "Статус": а не закрыт ли он уже ("только что") ? Ибо в селект этот выдаст строку в новом виде (с новым значением поля "Статус" и всех прочих) - тихо, без всякой ругани.
Остановился пока на дебильном
- выполнение его в RC обязательно вывалит ошибку, если было ожидание и конкурент успел обновить этот документ.

hvladДальше всё как обычно - RC имеет право видеть чужие изменения, сделанные после своего старта, а snapshot - не имеет такой возможности. Видеть - да. А менять ?

hvladСама запись читается позже.Хорошо: session #1 увидел заголовок. При no rec_version проверил, залочена ли она конкурентом. Оказалось - да, залочена, так что session #1 застрял на ней.
Дальше session #2 закоммитил изменения, и session #1 тут же получил запись.
ВИДЕТЬ запись в изменённом виде session #1, безусловно, ДОЛЖЕН, ведь это RC.
Но сам стейтмент от session #1 начался *ДО* этого коммита от session #2, так почему он вправе еще и МЕНЯТЬ запись, перетирать её ?

kdvТаблоид это самый натуральный lost update.
lost update - нормальная ситуация для rc.
- проходит на ура.Это и так понятно! Потому что у тебя время начала tr1 update и его коммита НЕ пересекается с временем начала tr2 update + tr2 commit.
Я же говорю про случай, когда:
И теперь в tr2 будет:
1) ОБЛОМ при rc REC_version и
2) ТИХОЕ ПЕРЕТИРАНИЕ при rc NO_rec_version
kdvа свой select for update with lock можешь заменить на простой update set a=a ...Дык!..

dimitrТаблоидКогда селект / апдейт стартует после чужого коммита - какие проблемы, всё ОК. Но когда он стартует *до*, молотит там что-то, а затем доходит до чужой залоченной записи и, дожидаясь её высвобождения, ТИХО перетираета какая половая разница (с точки зрения lost update в случае RC транзакции) между двумя этими случаями? Почему lost update в первом случае ты считаешь нормальным, но бесишься во втором?Да как это ?!
Если коннект-2 закоммитил запись и *после* этого любой стартующий стейтмент коннекта-1 будет обламываться - это как тогда работать-то ?!

Это всё шутка юмора, конечно. В текстах стандарта 2003 и 2006 я не вижу упоминания про т.н. "феномен-4" (P4), про который говорится тут . Но раз наступление этого "P4" блокируется при изменениях в rc rec_ver, то почему это же не сделано в rc NO_rec_ver ?

dimitrТаблоидИменно на сериализации доступа я и получил гемор.
Если есть документ, который надо перевести из статуса "Открыт" в статус "Закрыт", и к нему ломятся два и более аттача, то после успешного выполнения select for update в каждом аттаче надо еще раз проверять содержимое поля "Статус": а не закрыт ли он уже ("только что") ?
ты закрываешь пачку документов разом, что-ли? А нафига тут вообще что-то лочить?Нет, наоборот. Документы будут генериться 300 аттачами, они при этом будут в состоянии "НЕ закрыт".
Также будет создано 30 аттачей, каждый из которых будет выбирать случайный (или "не очень") документ для закрытия. Столкновение лбами кого-то из этих 30 аттачей неминуемо.

hvladТаблоидНо сам стейтмент от session #1 начался *ДО* этого коммита от session #2, так почему он вправе еще и МЕНЯТЬ запись, перетирать её ?А почему он не вправе это делать ?Если говорить об UPDATE (а не о select for update), то нелогично как-то выглядит: при rc rec_ ver в этой ситуации вываливается update conflict, и это - гут, так и должно быть.
А при no_ rec_ver этот же update уже тихо перетирает чужое изменение.
Если же говорить о SELECT for update, то он хотя и селект, но таки делается для последующего АПДЕЙТА. И если он увидел запись, которая была изменена и закоммичена после его старта, то вопить бы ему надо. Или автоматом перезапуститься, как это происходит в орацле.

hvladНе потому ли, что кто-то не понимает уровней изоляции тр-ций и принципов конкурентного программирования ?Что именно я не понимаю в TIL и причём тут "принципы конкурентного программирования" ? :-)

kdv"конфликт" вываливается при nowait . Что там кто перетирает - в wait. А?Йок! Конфликт в read committed вылазит только при record_version, а wait / no wait /lock timeout NN - побоку.
Во, смотри: То же самое будет при старте rc rec_ver с no wait, а также с lock timeout NN.

ЗЫ. Мне для теста WAIT - это смерти подобно, там вообще всё заткнётся. Надеюсь обойтись без него.