При работе с конфликтами у вас есть два варианта:
- Вы можете попытаться избежать конфликта, и именно это делает пессимистическая блокировка.
- Или вы могли бы допустить возникновение конфликта, но вам необходимо его обнаружить при совершении транзакций, и именно это делает 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
, следовательно, потеряет всю работу, которую мы проделали ранее выполняемой в данный момент транзакцией.
Чем больше разногласий, тем больше конфликтов и тем больше вероятность прерывания транзакций. Откат может быть дорогостоящим для системы баз данных, поскольку он должен отменить все текущие ожидающие изменения, которые могут включать как строки таблицы, так и записи индекса.
По этой причине пессимистическая блокировка может быть очень полезна, когда конфликты случаются часто, поскольку это снижает вероятность отката транзакций.