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

Как известно, существуют две стратегии блокировки: Optimistic vs. Pessimistic locking Может ли быть тупик при использовании оптимистической блокировки?

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

Также knonw, что Optimistic Concurrency Control не то же самое, как Multi Version Concurrency Control (Oracle или MSSQL-Snapshot/MVCC-RC): Optimistic vs Multi Version Concurrency Control - Differences?

Но может возникнуть затор между двумя транзакциями при использовании OCC (Optimistic Concurrency Control) в обоих?

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

источник

2016-08-14 Alex

Несомненно.

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

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

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

источник

2016-08-14 21:50:58

Спасибо! Поэтому Oracle Database никогда не увеличивает количество блокировок. Эскалация блокировки значительно увеличивает вероятность блокировок. Означает ли это, что «тупик» - это еще одно отличие Оптимистического параллелизма от параллелизма с несколькими версиями? Но на данный момент, когда Оптимистический параллелизм при завершении - чтение-проверка-изменение строки, мы используем блокировку? Или это может быть только один замок за транзакцию в один момент, поэтому не может быть тупиком. – Alex

@Alex - Я не уверен, что я понимаю последующие действия. Чтобы обновить строку, вам нужно ее заблокировать. Разница между оптимистичной и пессимистической блокировкой заключается в том, пессимистично ли вы блокируете строку на случай, если вы ее обновите, или вы оптимистично ожидаете, пока не узнаете, что хотите ее обновить, чтобы получить блокировку. Вы можете написать приложение, каждое из которых выполнялось как отдельная транзакция.Это уменьшило бы тупики, но это было бы ужасно для согласованности данных. –

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

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

источник

2016-12-01 11:19:37

Спасибо! Но классическое определение оптимистического контроля параллелизма, которое реализуется с использованием аппаратной транзакционной памяти, может ли оно иметь свойство скомпрометировать? https://en.wikipedia.org/wiki/Software_transactional_memory#Composable_operations – Alex

Также кажется, что наименьшая вероятность блокировок при использовании «уровня сериализованной изоляции», когда любая из модификаций будет видна только после совершения транзакции, а Том Ките сказал: этот serializable является одним из способов достижения высокой пропускной способности и более быстрого времени отклика ", из которого можно сделать вывод, что столкновений потоков меньше. https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:12684560615138 Верно ли, что использование OCC может быть реализовано только на уровне сериализованной изоляции MVCC или other: Read-Committed, Repeatable-read, Snapshot? – Alex

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

ответ

Смежные вопросы