Обе формы блокировки заставляют процесс ожидать правильной копии записи, если она в данный момент используется другим процессом. При пессимистической блокировке механизм блокировки происходит от самой БД (собственный объект блокировки), в то время как при оптимистической блокировке механизм блокировки представляет собой некоторую форму контроля версий строк, такую как отметка времени, чтобы проверить, является ли запись «устаревшей» или нет.
Но оба приводят к зависанию второго процесса. Поэтому я спрашиваю: почему оптимистическая блокировка обычно считается быстрее / лучше, чем пессимистическая блокировка? И есть ли случаи использования, когда пессимистический предпочтительнее, чем оптимистичный? Заранее спасибо!
performance
locking
rdbms
Mara
источник
источник
Ответы:
Двойной вопрос от:
/programming/129329/optimistic-vs-pessimistic-locking
Скопируйте / вставьте ответ по вышеуказанной ссылке:
Оптимистическая блокировка - это стратегия, при которой вы читаете запись, записываете номер версии и проверяете, что версия не изменилась, прежде чем записывать запись обратно. Когда вы записываете запись обратно, вы фильтруете обновление версии, чтобы убедиться, что оно атомарное. (т.е. не обновлялся между проверкой версии и записью записи на диск) и обновлением версии одним нажатием.
Если запись грязная (т. Е. Версия отличается от вашей), вы прерываете транзакцию, и пользователь может перезапустить ее.
Эта стратегия наиболее применима к системам большого объема и трехуровневым архитектурам, где вы не обязательно поддерживаете соединение с базой данных для вашего сеанса. В этой ситуации клиент фактически не может поддерживать блокировки базы данных, так как соединения берутся из пула, и вы не можете использовать одно и то же соединение для одного доступа к другому.
Пессимистическая блокировка - это когда вы блокируете запись для своего эксклюзивного использования до тех пор, пока не закончите с ней. Он имеет гораздо лучшую целостность, чем оптимистичная блокировка, но требует от вас осторожности при разработке приложения, чтобы избежать тупиковых ситуаций. Чтобы использовать пессимистическую блокировку, вам необходимо либо прямое соединение с базой данных (как это обычно бывает в двухуровневом клиент-серверном приложении), либо внешне доступный идентификатор транзакции, который можно использовать независимо от соединения.
В последнем случае вы открываете транзакцию с TxID, а затем повторно подключаетесь с использованием этого идентификатора. СУБД поддерживает блокировки и позволяет вам забрать сеанс обратно через TxID. Именно так работают распределенные транзакции, использующие протоколы двухфазной фиксации (такие как транзакции XA или COM +).
Изменить (добавив больше информации для решения вопроса производительности):
Производительность зависит от вашей среды. Примите во внимание следующие факторы:
вы найдете оптимизм лучше из-за параллелизма в большинстве ситуаций. Однако в зависимости от СУБД и среды это может быть менее или более производительным. Как правило, с Оптимистической блокировкой вы обнаружите, что значение должно быть где-то версировано.
Например, в MS SQL Server он перемещается в TempDB, и в конце столбца добавляется что-то между 12-14 байтами. Включение оптимистической блокировки с уровнем изоляции, таким как изоляция моментальных снимков, может привести к фрагментации, и необходимо будет скорректировать коэффициент заполнения, так как строки теперь имеют дополнительные данные в конце, что может привести к тому, что страница почти заполнится, что приведет к разделению страницы, что приведет к снижению ваше выступление. Если ваша TempDB недостаточно оптимизирована, это будет не так быстро.
Итак, я думаю, контрольный список:
Это мои мысли по этому вопросу, открытые для получения дополнительной информации от сообщества.
источник
Вы неправильно понимаете оптимистическую блокировку.
Оптимистическая блокировка не заставляет транзакции ждать друг друга.
Оптимистическая блокировка может привести к сбою транзакции, но это происходит без какой-либо «блокировки». И если транзакция завершается неудачно из-за оптимистической блокировки, пользователь должен начать все сначала. Слово «оптимистический» происходит именно от ожидания того, что условие, которое приводит к сбою транзакций по этой самой причине, будет происходить только в очень исключительных случаях. «Оптимистическая» блокировка - это подход, который гласит: «Я не буду брать настоящие блокировки, потому что надеюсь, что они все равно не понадобятся. Если окажется, что я ошибался в этом, я приму неизбежный сбой».
источник
Оптимистическая блокировка, как правило, быстрее, потому что в действительности нет блокировки с точки зрения базы данных. Это полностью зависит от приложения, уважать ли столбец версии (или псевдостолбец, например, ora_rowscn) или нет. Обычно у вас есть много приложений, подключенных к одной и той же базе данных, поэтому db становится общим ресурсом, и если он зависает, все клиенты будут затронуты.
При оптимистичной стратегии блокировки «зависание» происходит на стороне клиента и не влияет на других.
Однако, если запись часто обновляется, вы можете перечитать ее слишком много раз (в случае оптимистической блокировки), что лишит вас преимуществ от оптимистической стратегии.
Я не согласен с превосходством любого подхода; оба они могут быть использованы неправильно. Pessimistic более подвержен ошибкам только потому, что он более опасен: блокировка происходит на уровне базы данных, зависит от RDMS, у вас может не быть контроля над тем, что заблокировано (эскалация блокировки), вам нужно позаботиться о порядке блокировки вручную.
источник
Оптимистическая блокировка предполагает, что параллельные транзакции могут завершаться без влияния друг на друга. Таким образом, оптимистическая блокировка работает быстрее, поскольку при выполнении транзакций блокировки не применяются. Это предотвращение возникновения параллелизма, а не лечение. Транзакция просто проверяет (тремя способами наборы данных, тип данных временной метки, проверить старое и новое значение) данные, которые никакая другая транзакция не изменила. В случае модификации транзакция откатывается.
Пессимистическая блокировка предполагает, что параллельные транзакции будут конфликтовать друг с другом, поэтому она требует блокировки, это делается путем указания уровня ИЗОЛЯЦИИ (Чтение незафиксированного, Чтение зафиксированного, Повторяемое чтение и Сериализуемый) управления транзакциями. Он устраняет проблемы параллелизма путем получения блокировки. блокировки служат для защиты общих ресурсов или объектов (таблиц, строк данных, блоков данных, кэшированных элементов, соединений и целых систем). У нас есть много типов блокировок, таких как общие блокировки, блокировки обновлений, блокировки вставок, эксклюзивные блокировки, блокировки транзакций, блокировки DML, блокировки схемы и блокировки резервного копирования и восстановления.
чтобы получить больше идеи
источник
Неправильно утверждать, что пессимистическая блокировка медленнее, чем оптимистична, или говорить, что оптимистичность быстрее. Один классический запрос для демонстрации такого неподходящего способа мышления - это агрегирование в различных СУБД, например:
Вы увидите, что в СУБД, которые поддерживают нативно-оптимистический подход, время, затрачиваемое на этот запрос, значительно значительнее, чем у тех, кто имеет изначально пессимистическую блокировку.
Например, на моем ПК тот же запрос занимает 27 мс на SQL Server и 109 мс на PostGreSQL ...
Дополнительные затраты, необходимые для чтения мертвых версий строк MVCC и не учитывающие записи о привидениях в совокупности, увеличивают затраты, которых нет у пессимиста!
источник