Оптимистическая и пессимистическая блокировка

Я понимаю разницу между оптимистической и пессимистической блокировкой. Может ли кто-нибудь объяснить мне, когда я буду использовать один из них вообще?

И меняется ли ответ на этот вопрос в зависимости от того, использую ли я хранимую процедуру для выполнения запроса?

Но просто для проверки оптимистический означает «не блокировать таблицу во время чтения», а пессимистический означает «заблокировать таблицу во время чтения».

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

Если запись грязная (т. Е. Версия отличается от вашей), вы прерываете транзакцию, и пользователь может перезапустить ее.

Эта стратегия наиболее применима к системам большого объема и трехуровневым архитектурам, где вы не обязательно поддерживаете соединение с базой данных для вашего сеанса. В этой ситуации клиент фактически не может поддерживать блокировки базы данных, так как соединения берутся из пула, и вы не можете использовать одно и то же соединение для одного доступа к другому.

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

В последнем случае вы открываете транзакцию с TxID, а затем повторно подключаетесь с использованием этого идентификатора. СУБД поддерживает блокировки и позволяет вам забрать сеанс обратно через TxID. Именно так работают распределенные транзакции, использующие протоколы двухфазной фиксации (такие как транзакции XA или COM + ).

Оптимистическая блокировка используется, когда вы не ожидаете много столкновений. Обычная операция обходится дешевле, но если коллизия ДЕЙСТВИТЕЛЬНО произойдет, вы заплатите более высокую цену за ее разрешение при отмене транзакции.

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

Чтобы выбрать правильный механизм блокировки, вы должны оценить количество операций чтения и записи и составить соответствующий план.

Оптимистический предполагает, что ничего не изменится, пока вы читаете это.

Пессимистично предполагает, что что-то будет, и поэтому блокирует это.

Если не важно, что данные идеально читаются, используйте оптимизм. Вы можете получить странное «грязное» прочтение, но оно гораздо менее вероятно приведет к тупикам и тому подобному.

Большинство веб-приложений хорошо справляются с грязным чтением - в редких случаях данные не совсем соответствуют следующей перезагрузке.

Для точных операций с данными (как и во многих финансовых транзакциях) используйте пессимистический подход. Очень важно, чтобы данные были точно прочитаны, без каких-либо непредвиденных изменений - дополнительные издержки блокировки того стоят.

Да, и сервер Microsoft SQL по умолчанию блокирует страницу - в основном, строку, которую вы читаете, и несколько по обе стороны. Блокировка строк более точна, но намного медленнее. Часто стоит установить транзакции на фиксацию или отсутствие блокировки, чтобы избежать тупиков при чтении.

В дополнение к тому, что уже было сказано:

• Следует сказать, что optimisticблокировка имеет тенденцию улучшать параллелизм за счет предсказуемости.
• PessimisticБлокировка имеет тенденцию уменьшать параллелизм, но более предсказуема. Вы платите свои деньги и т.д ...

При работе с конфликтами у вас есть два варианта:

• Вы можете попытаться избежать конфликта, и именно это делает пессимистическая блокировка.
• Или вы могли бы допустить возникновение конфликта, но вам необходимо его обнаружить при совершении транзакций, и именно это делает Optimistic Locking.

Теперь давайте рассмотрим следующую аномалию Lost Update :

Аномалия Lost Update может возникнуть на уровне изоляции Read Committed .

На диаграмме выше мы видим, что Алиса считает, что она может снять с нее 40, accountно не понимает, что Боб только что изменил остаток на счете, и теперь на этом счете осталось только 20.

Пессимистическая блокировка

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

На приведенной выше диаграмме Алиса и Боб получат блокировку чтения accountстроки таблицы, которую оба пользователя прочитали. База данных получает эти блокировки на SQL Server при использовании Repeatable Read или Serializable.

Поскольку Алиса и Боб прочитали значение accountсо значением PK 1, ни один из них не может изменить его, пока один пользователь не снимет блокировку чтения. Это связано с тем, что операция записи требует получения блокировки записи / эксклюзивной блокировки, а блокировки совместного использования / чтения предотвращают блокировку записи / эксклюзивной блокировки.

Только после того, как Алиса зафиксировала свою транзакцию и сняла блокировку чтения в accountстроке, Боб UPDATEвозобновит и применит изменения. Пока Алиса не снимет блокировку чтения, Боб UPDATE блокирует.

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

Оптимистическая блокировка

Оптимистическая блокировка позволяет конфликту возникать, но обнаруживает его после применения ОБНОВЛЕНИЯ Алисы по мере изменения версии.

На этот раз у нас есть дополнительный versionстолбец. versionСтолбца увеличивается каждый раз , когда UPDATE или DELETE выполняется, и он также используется в предложении WHERE в UPDATE и DELETE заявления. Чтобы это работало, нам нужно выполнить SELECT и прочитать текущее значение versionперед выполнением UPDATE или DELETE, так как в противном случае мы не знали бы, какое значение версии передать в предложение WHERE или увеличить.

Для получения дополнительной информации о том, как платформы доступа к данным реализуют оптимистическую блокировку, ознакомьтесь с этой статьей .

Транзакции уровня приложения

Системы реляционных баз данных появились в конце 70-х начале 80-х годов, когда клиент, как правило, подключался к мэйнфрейму через терминал. Вот почему мы до сих пор видим, что системы баз данных определяют такие термины, как настройка SESSION.

В настоящее время через Интернет мы больше не выполняем операции чтения и записи в контексте одной и той же транзакции базы данных, и ACID больше не достаточно.

Например, рассмотрим следующий вариант использования:

Без оптимистической блокировки это потерянное обновление невозможно было бы перехватить, даже если бы транзакции базы данных использовали Serializable. Это связано с тем, что чтение и запись выполняются в отдельных HTTP-запросах, следовательно, в разных транзакциях базы данных.

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

Дополнительные сведения об уровне приложения или логических транзакциях см. В этой статье .

Вывод

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

Недостаток оптимистичной блокировки заключается в том, что откат будет инициирован средой доступа к данным при перехвате, и OptimisticLockException, следовательно, потеряет всю работу, которую мы проделали ранее выполняемой в данный момент транзакцией.

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

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

Я бы подумал еще об одном случае, когда пессимистическая блокировка была бы лучшим выбором.

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

Есть в основном два самых популярных ответа. Первый один в основном говорит ,

Для Optimistic требуется трехуровневая архитектура, в которой вы не обязательно поддерживаете соединение с базой данных для своего сеанса, тогда как Pessimistic Locking - это когда вы блокируете запись для своего эксклюзивного использования до тех пор, пока не закончите с ней. У него гораздо лучшая целостность, чем у оптимистической блокировки, вам нужно либо прямое подключение к базе данных.

Другой ответ

Оптимистическое (управление версиями) быстрее из-за отсутствия блокировок, но (пессимистическое) блокирование работает лучше, когда конкуренция высока, и лучше предотвращать работу, чем отбрасывать ее и начинать заново.

или

Оптимистическая блокировка работает лучше всего при редких столкновениях

Как это написано на этой странице.

Я создал свой ответ, чтобы объяснить, как «сохранить соединение» связано с «низкими коллизиями».

Чтобы понять, какая стратегия лучше для вас, подумайте не о транзакциях в секунду, которые имеет ваша БД, а о продолжительности одной транзакции. Обычно вы открываете trasnaction, Performa Operation и закрываете транзакцию. Это короткая, классическая транзакция, которую ANSI имела в виду, и она прекрасно подходит для блокировки. Но как реализовать систему бронирования билетов, когда многие клиенты бронируют одни и те же номера / места одновременно?

Вы просматриваете предложения, заполняете форму множеством доступных опций и актуальными ценами. Это занимает много времени, и варианты могут устареть, все недействительные цены между вами начали заполнять форму и нажать кнопку «Я согласен», потому что не было блокировки данных, к которым вы обращались, и кто-то другой, более проворный, вмешался меняются все цены и вам нужно перезапустить с новыми ценами.

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

При таком оптимистичном подходе вы должны записать все данные, которые вы прочитали (как в моем Повторном чтении ), и прийти к точке фиксации с вашей версией данных (я хочу покупать акции по цене, указанной в этой цитате, а не по текущей цене). ). На этом этапе создается транзакция ANSI, которая блокирует БД, проверяет, ничего не изменилось и фиксирует / прерывает вашу операцию. IMO, это эффективная эмуляция MVCC , которая также связана с Optimistic CC и также предполагает, что ваша транзакция перезапускается в случае сбоя, то есть вы сделаете новое резервирование. Транзакция здесь включает в себя решения пользователя.

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

В большинстве случаев оптимистичная блокировка более эффективна и обеспечивает более высокую производительность. При выборе между пессимистической и оптимистической блокировками учитывайте следующее:

• Пессимистическая блокировка полезна, если есть много обновлений и относительно высокие шансы пользователей пытаться обновлять данные одновременно. Например, если каждая операция может обновлять большое количество записей за один раз (банк может добавлять процентные доходы к каждой учетной записи в конце каждого месяца), и два приложения выполняют такие операции одновременно, они будут иметь конфликты ,

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

• Оптимистическая блокировка полезна, если вероятность конфликтов очень мала - существует много записей, но относительно мало пользователей, или очень мало обновлений и в основном операций типа чтения.

Один из вариантов использования оптимистической блокировки - это использование приложением базы данных, чтобы один из ваших потоков / хостов мог «требовать» выполнения задачи. Это метод, который мне пригодился на регулярной основе.

Лучший пример, который я могу придумать, - это очередь задач, реализованная с использованием базы данных, когда несколько потоков одновременно выполняют задачи. Если задача имеет статус «Доступно», «Заявлено», «Завершено», запрос БД может сказать что-то вроде «Установить статус =« Заявлено », где статус =« Доступно ». Если несколько потоков пытаются изменить статус таким способом, все, кроме первого потока, потерпят неудачу из-за грязных данных.

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

Много хорошего было сказано выше об оптимистической и пессимистической блокировке. Один важный момент для рассмотрения заключается в следующем:

При использовании оптимистической блокировки, мы должны быть осторожны с тем, как приложение восстановится после этих сбоев.

Особенно в асинхронных архитектурах, управляемых сообщениями, это может привести к неправильной обработке сообщений или к потере обновлений.

Сценарии отказов необходимо продумать.