|
_Vasilisk_1) Транзакции read_commited, rec_version
ну слава богу!
_Vasilisk_И все таки смысла isc_update_conflict я не понял. "Чтобы не приходилось в саппорте отвечать на вопросы" - как-то неубедительно звучит
есть две модели обработки такого конфликта
Допустим, есть А, делает update, и есть Б, делает update в wait.
1. при commit транзакции А транзакция Б обломится, т.е. получит ошибку lock conflict ибо конкурирующая транзакция ИЗМЕНИЛА данные, а на какие, хрен его знает, поэтому транзации Б запрещается их перезаписывать. Так работает InterBase и Firebird
2. при commit транзакции А транзакция Б перепишет сделанные ею изменения, и не получит ошибки о конкурирующем update. Так, вроде бы, сделано в Оракле.
На клиентской стороне у ДатаСетов бывают аналогии этому поведению. Не в смысле конкурентного обновления, а в смысле убивания изменений, сделанных предыдущей транзакцией. То есть, перед входом в режим редактирования запоминаются столбцы строки, а при отправке update формируется запрос, который не проверяет ничего, проверяет изменения, или проверяет все.
upWhereKeyOnly - проверяется только ID записи, на остальное кладется болт
upWhereChanged - проверяются столбцы, которые менялись, плюс ID. Если старые значения уже не те, что были считаны перед переходом в режим редактирования, выдается ошибка.
upWhereAll - тут контролируются все столбцы, независимо, менялись они при редактировании, или нет. Главное, чтобы все столбцы имели те же значения при update, что и до "входа" в режим редактирования.
Если в отношении клиентской стороны (т.е. sql запросов) можно выбирать - класть болт на изменения или наоборот, их учитывать, то в отношении конкурирующих транзакций сервер поступает всегда единообразно, так, как в нем была реализована модель обработки таких конфликтов.
Также, не надо забывать, что транзакция snapshot при получении конфликта конкурентного update хоть в wait, хоть в nowait, не может "повторить update", т.к. в силу своего уровня изолированности она физически не может увидеть эти изменения, и соответственно, их переписать.
То есть, если для RC поведение Оракла еще бы имело смысл (например, типа, "давайте так же сделаем в ФБ"), то для snapshot - увы, никак и никогда. То есть, поведение обработки конфликта в ФБ в RC соответствует таковому в snapshot.
Однако, отлуп в ФБ в RC считается логичным, потому что если Б повисла на конфликте, то она до завершения А коммитом не в состоянии "увидеть" что изменила А. И это является индикацией, что до изменений Б кто-то уже успел запись изменить. Благо, как я уже сказал, RC по такой ошибке позволяет перечитать данные закоммиченные транзакцией А, и дальше решить, повторять update, или нет.
|
