Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
 О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
День добрый.
Никак не могу понять, как fb разруливает апдейты одной и той же записи. (возможно плохо искал)
Так вот, периодически у меня вылезает проблема конфликта обновлений, параметры транзакций выставлены как rec_ver и wait.
Сегодня словил вышеописанную проблему, стартонула транзакция, которая делает апдейт записи, спустя секунду стартонула вторая транзакция, которая апдейтит ту же запись, что и первая. В итоге вторая тр завершилась, а первая откатилась с ошибкой конфликта обновлений.
Буду очень признателен, если кто-то разъяснит из-за чего происходит такая ситуация (fb 3.0.5 ss).

Сообщение было отредактировано: 9 июл 20, 22:39
9 июл 20, 22:40    [22164913]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

Чти: http://www.ibase.ru/transactions/

Posted via ActualForum NNTP Server 1.5

10 июл 20, 00:21    [22164958]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
demon1992
В итоге вторая тр завершилась, а первая откатилась с ошибкой конфликта обновлений.

Раз используется wait, тогда тут всё нормально. Потому что вторая-то сделала коммит, а первая "не успела" обновить,
и значит после коммита конкурента должна перечитать данные (если это не snapshot).
Вообще с Firebird wait если и надо, то в специфических случаях.
Лучше no wait, т.е. получать сообщения о конфликте обновлений сразу. Это не MS SQL, который изменения накатывает записывает по коммиту. В FB изменения идут сразу "по месту", а коммитом они только подтверждаются.

Кроме
http://www.ibase.ru/transactions/

если используете FIBPlus, FireDAC или подобные - то желательно прочитать и http://www.ibase.ru/ibx/
10 июл 20, 01:44    [22164966]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
Статью читал, и ролик смотрел.
Я почему то всегда думал, что движок разруливает эти самые блокировки тем, что если обнаруживает незакоммиченные данные, новая транзакция не будет сразу вываливать ошибку, а будет пытаться сделать несколько попыток обновить запись.
Но я всё равно не понимаю, как в высоконагруженной системе с конкурентным доступом, работает без проблем, а потом раз в полгода вываливается ошибка конфликта обновлений.
10 июл 20, 08:13    [22164995]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10418
demon1992
Но я всё равно не понимаю, как в высоконагруженной системе с конкурентным доступом, работает без проблем, а потом раз в полгода вываливается ошибка конфликта обновлений.
"Высоконагруженная" это сколько?
Тысячи роботов или сотни пользователей? А сотни пользователей работают как роботы или, всё-таки, менее интенсивно?
Ну и самое главное - вы, конечно, уже знаете, сколько времени занимает типичная транзакции и какова вероятность конфликта обновлений?
10 июл 20, 08:38    [22165002]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
Не роботы, но транзакций много, пишущая транзакция работает быстро, меньше секунды.
10 июл 20, 09:10    [22165016]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
Вообще у меня вопрос в другом: ждет ли движок какое-то время чтобы повторно накатить изменения, если натыкается на незакоммиченные данные?
И как так получилось, что тр2 обновила запись, при запущенной ранее тр1, которая так же обновляла ту самую запись что и тр2.
10 июл 20, 09:18    [22165020]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
Я немного не договорил еще. Запись обновляется процедурой, и перед выполнением есть еще исполняемый код. Могло ли получится так, что тр2 начала обновлять запись раньше чем тр1, и из-за этого и получить конфликт обновления? Если так, то это очень странно, в процедуре перед обновлением идет всего пару единичных селектов по индексу, там нет ничего такого что могло бы зависнуть, а разница между стартом транзакций 1.5 сек.
10 июл 20, 09:38    [22165031]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
hvlad
Member

Откуда:
Сообщений: 10993
demon1992
Вообще у меня вопрос в другом: ждет ли движок какое-то время чтобы повторно накатить изменения, если натыкается на незакоммиченные данные?
Если он их увидел до того как начал читать запись, и если это READ COMMITTED NO RECORD VERSION тр-ция - ждёт
- если конкурент откатился - читаем и идём дальше,
- если конкурент подтвердился ещё активен, то выдаёт isc_read_conflict,
- если конкурент подтвердился - RC NRV тр-ция читает первичную версию.
Другие тр-ции не ждут и ищут видимую для них бекверсию.

Далее, если запись была нами прочитана, но была изменена конкурентом в промежутке между чтением и самим апдейтом, то снова ждём финального состояния конкурента (если мы READ COMMITTED) и
- если конкурент откатился - пишем свою версию,
- если конкурент ещё активен или подтвердился, то выдаём isc_update_conflict.

Это на пальцах, там больше деталей на самом деле.

PS В 4-ке на уровне READ COMMITTED READ CONSISTENCY алгоритм сложнее и может полностью исключить isc_update_conflict в большинстве случаев

PPS исправил немного

Сообщение было отредактировано: 10 июл 20, 10:10
10 июл 20, 10:04    [22165043]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
hvlad
Member

Откуда:
Сообщений: 10993
demon1992
И как так получилось, что тр2 обновила запись, при запущенной ранее тр1, которая так же обновляла ту самую запись что и тр2.
Если tx1 обновила запись и была comitted, то tx2 вполне может её менять. Если tx2 - RC, то неважно кто из них когда стартовал.
10 июл 20, 10:06    [22165044]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
demon1992
а будет пытаться сделать несколько попыток обновить запись

зачем это движку?
В общем, читать надо http://www.ibase.ru/mga/
и убирать wait из параметров транзакций.

"транзакций много" - сколько, миллион в сутки, два, пять?
10 июл 20, 10:31    [22165054]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
hvlad,

Спасибо за разъяснение.
10 июл 20, 10:42    [22165061]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
demon1992
Member

Откуда:
Сообщений: 90
kdv,

Бывает и 5 и 10 и 20.
10 июл 20, 10:45    [22165063]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Softologic
Member

Откуда: Питер
Сообщений: 155
demon1992,

Есть еще пара полезных видосов, помимо чтива:

+

10 июл 20, 11:14    [22165077]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 10418
demon1992
Бывает и 5 и 10 и 20.
20млн / 86400 ~= 232 транзакции в секунду.
С учётом того, что есть периоды пиковой активности, (вероятно) не все транзакции пишущие и далеко не все пишущие транзакции вообще могут конфликтовать - получаем, что вероятность конфикта "достаточно мала".
Собственно именно это и составляет корень проблемы "вот тут мы не будем делать правильно, но сложно": более простой вариант работает почти всегда.
10 июл 20, 11:38    [22165098]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

kdv
зачем это движку?

Ну, в четвёрке что-то такое сделали...

kdv
и убирать wait из параметров транзакций.

А вот это вопрос спорный. С одной стороны да, хорошо получать ошибку сразу. С другой
стороны естественная (и практически единственная вменяемая) реакция на эту ошибку -
откатить транзакцию, перечитать данные и попробовать снова. И вот тут-то хорошо бы таки
подождать пока конкурент завершится, иначе будем долбиться как дятлы.

Posted via ActualForum NNTP Server 1.5

10 июл 20, 12:53    [22165166]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
hvlad
Member

Откуда:
Сообщений: 10993
Dimitry Sibiryakov
kdv
и убирать wait из параметров транзакций.

А вот это вопрос спорный.
Согласен.
Если говорить о пар-рах тр-ции с точки зрения апдейтов, то тот, кто читал хотя бы 22165043, не мог не заметить, что использование RC NRV
значительно сокращает вероятность конфликтов обновления. Особенно при не очень высокой конкуренции.
Но, конечно, не гарантирует их отсутствие.
Новый режим RC RC в 4-ке уменьшает эту вероятность почти до нуля.
10 июл 20, 13:15    [22165183]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Dimitry Sibiryakov
реакция на эту ошибку - откатить транзакцию

это только если snapshot. там другого варианта и нет.
А с read committed вполне можно перечитать запись, и дальше решать - опять пытаться обновлять ее, или нет.
Dimitry Sibiryakov
Ну, в четвёрке что-то такое сделали...

да нет там ничего такого.
10 июл 20, 15:03    [22165315]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
hvlad
Member

Откуда:
Сообщений: 10993
kdv
Dimitry Sibiryakov
Ну, в четвёрке что-то такое сделали...

да нет там ничего такого.
https://github.com/FirebirdSQL/firebird/blob/master/doc/README.read_consistency.md

Читать до прояснения, особенно главу "Update conflicts handling"
10 июл 20, 15:16    [22165328]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50808

kdv
с read committed вполне можно перечитать запись, и дальше решать - опять пытаться
обновлять ее, или нет.

А смысл это делать до того, как конкурент завершится?..

Posted via ActualForum NNTP Server 1.5

10 июл 20, 15:22    [22165338]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 29015
Dimitry Sibiryakov
А смысл это делать до того, как конкурент завершится?..

как раз и проверять, завершился он или нет.
hvlad
Читать до прояснения

да, действительно "долбит". Ну и ладно.
10 июл 20, 15:37    [22165355]     Ответить | Цитировать Сообщить модератору
 Re: О блокировках  [new]
hvlad
Member

Откуда:
Сообщений: 10993
kdv
Dimitry Sibiryakov
А смысл это делать до того, как конкурент завершится?..

как раз и проверять, завершился он или нет.
И как ты собрался это проверять ?


kdv
да, действительно "долбит". Ну и ладно.
Я же просил - до прояснения. Никто никого не "долбит". Дятлы давно все улетели ;)
10 июл 20, 15:42    [22165359]     Ответить | Цитировать Сообщить модератору
Все форумы / Firebird, InterBase Ответить