Может ли быть тупик при использовании оптимистической блокировки?

Как известно, существует две стратегии блокировки: оптимистическая и пессимистическая блокировка.

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

Также известно, что Оптимистическое управление параллелизмом - это не то же самое, что Управление параллелизмом нескольких версий (Oracle или MSSQL-Snapshot / MVCC-RC): Оптимистичный и многоверсионный контроль параллелизма - различия?

Но может ли возникнуть взаимоблокировка между двумя транзакциями, если используется OCC (Оптимистический контроль параллелизма) в обоих?

Можно ли сказать, что оптимистическая блокировка снижает вероятность тупиковой ситуации за счет уменьшения согласованности? И только если каждое обновление происходит в отдельной транзакции, то вероятность тупиковой ситуации составляет 0%, но при этом наименьшая согласованность.


sql-server oracle locking optimistic-locking pessimistic-locking
person Alex    schedule 14.08.2016    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Конечно.

Тупик просто означает, что поток A удерживает блокировку, которую ожидает поток B, в то время как B держит блокировку, которую ожидает A. Если ваше приложение не предназначено для блокировки ресурсов в одном и том же порядке повсюду, достаточно легко зайти в тупик независимо от вашей стратегии блокировки.

Представьте, что потоки A и B оба хотят обновить конкретную строку в родительской таблице и в дочерней таблице. Поток A сначала обновляет родительскую строку. Поток B сначала обновляет дочернюю строку. Теперь поток A пытается обновить дочернюю строку и оказывается заблокированным B. Тем временем поток B пытается обновить родительскую строку и оказывается заблокированным A. У вас тупиковая ситуация.

Если у вас был последовательный порядок блокировки ресурсов (т.е. всегда блокировал родительский элемент перед дочерним) в Oracle, вы не получите взаимоблокировок независимо от вашей стратегии блокировки. Обычно в SQL Server не возникает взаимоблокировок, но возможность эскалации блокировок на уровне строк в SQL Server делает это менее надежным.

person Justin Cave    schedule 14.08.2016
comment
Спасибо! Поэтому Oracle Database никогда не наращивает блокировки. Эскалация блокировки значительно увеличивает вероятность возникновения тупиковых ситуаций. Означает ли это, что тупик - это еще одно отличие оптимистичного параллелизма от одновременного управления несколькими версиями? Но в тот момент, когда оптимистичный параллелизм по завершении - чтение-проверка-изменение строки, используем ли мы блокировку? Или это может быть только одна блокировка на транзакцию в один момент, поэтому не может быть тупиковой блокировки. - person Alex; 15.08.2016
comment
@Alex - Я не уверен, что понимаю дальнейшие действия. Чтобы обновить строку, вы должны заблокировать ее. Разница между оптимистической и пессимистической блокировкой заключается в том, блокируете ли вы строку пессимистично на тот случай, если вы можете ее обновить, или вы оптимистично ждете, пока не узнаете, что хотите обновить ее, чтобы получить блокировку. Вы можете написать приложение, которое будет выполнять каждое обновление как отдельную транзакцию. Это уменьшило бы количество взаимоблокировок, но было бы ужасно для согласованности данных. - person Justin Cave; 15.08.2016
comment
Да, спасибо, это то, что я хотел знать. Можно ли сказать, что оптимистическая блокировка снижает вероятность тупиковой ситуации за счет уменьшения согласованности? И только если каждое обновление в отдельной транзакции, то вероятность тупиковой ситуации равна 0%, но при этом согласованность наименьшая. Используя определенный оптимистичный подход, мы можем достичь необходимого компромисса между тупиком и согласованностью. - person Alex; 15.08.2016
comment
@Alex - В Oracle взаимоблокировки не являются компромиссом. Независимо от того, используете ли вы оптимистичную или пессимистичную блокировку, если вы правильно напишете код, вы никогда не попадете в тупик. В SQL Server, если исключить случаи, когда блокировки увеличиваются, что должно быть очень редко в системе OLTP, вы никогда не должны попадать в тупик. Если ваше приложение заходит в тупик, значит, оно написано плохо. - person Justin Cave; 15.08.2016
comment
Я считаю, что избежать тупиковых ситуаций с помощью пессимистической схемы блокировки может быть намного сложнее. С такой схемой вы обычно блокируете строку исключительно тогда, когда пользователь сигнализирует о своем намерении изменить ее (то есть, когда он впервые редактирует любой столбец в строке). Поскольку вы не можете контролировать порядок, в котором каждый пользователь редактирует данные, которые он видит, вы не можете гарантировать, что взаимоблокировки не возникнут. В оптимистической модели блокировки вы ничего не блокируете исключительно до тех пор, пока объект не сохранит свою работу. На этом этапе вы знаете все затронутые строки и можете заблокировать их в последовательном порядке (например, по возрастанию идентификатора или что-то в этом роде). - person Matthew McPeak; 15.08.2016
comment
Я не уверен, что это правильно. Насколько я понимаю, оптимистическая блокировка не блокирует ресурсы. Я ошибся? - person Florian Wicher; 27.12.2019

arrow_upward
7
arrow_downward

Боюсь, что вы должны быть очень точными в своем определении оптимистичного управления параллелизмом. В классическом определении Бернштейна, Гудмана и Хадзилакоса оптимистичное управление параллелизмом позволяет потокам «виртуально» получать блокировки, выполнять обновления, а затем проверять нарушение согласованности, когда транзакция пытается зафиксировать. Если происходит нарушение согласованности, транзакция принудительно прерывается и отправляется повторно. В соответствии с этим определением неясно, как может возникнуть взаимоблокировка, поскольку потоки «никогда» не блокируются в ожидании блокировки. Классическое определение оптимистичного управления параллелизмом нелегко реализовать на практике. Однако недавние исследования аппаратной транзакционной памяти открывают некоторые возможности и меняют точку зрения на эту старую проблему.

person Mootaz Elnozahy    schedule 01.12.2016
comment
Спасибо! Но классическое определение оптимистичного управления параллелизмом, которое реализовано с использованием аппаратной транзакционной памяти - может ли оно иметь возможность компоновки свойств? en.wikipedia.org/wiki/ - person Alex; 01.12.2016
comment
Также кажется, что наименьшая вероятность возникновения взаимоблокировок при использовании уровня изоляции serialazable, когда любая из модификаций будет видна только после фиксации транзакции, и Том Кайт сказал, что сериализуемость - это один из способов достижения высокой пропускной способности и более быстрого времени отклика, из которого можно сделать вывод. что меньше столкновений потоков. asktom.oracle.com/pls / apex / Верно ли, что с помощью OCC можно реализовать в MVCC только сериализуемый уровень изоляции или любой другой: Read-Committed, Repeatable-read, Snapshot? - person Alex; 01.12.2016
comment
Это должен быть правильный ответ: OCC по определению свободен от тупиков. - person mljrg; 26.06.2018
comment
Почему классическое определение оптимистичного управления параллелизмом нелегко реализовать на практике. ? Есть ли ссылки, объясняющие это? Спасибо - person mljrg; 26.06.2018