Двойной вопрос от:
/programming/129329/optimistic-vs-pessimistic-locking
Скопируйте / вставьте ответ по вышеуказанной ссылке:
Оптимистическая блокировка - это стратегия, при которой вы читаете запись, записываете номер версии и проверяете, что версия не изменилась, прежде чем записывать запись обратно. Когда вы записываете запись обратно, вы фильтруете обновление версии, чтобы убедиться, что оно атомарное. (т.е. не обновлялся между проверкой версии и записью записи на диск) и обновлением версии одним нажатием.
Если запись грязная (т. Е. Версия отличается от вашей), вы прерываете транзакцию, и пользователь может перезапустить ее.
Эта стратегия наиболее применима к системам большого объема и трехуровневым архитектурам, где вы не обязательно поддерживаете соединение с базой данных для вашего сеанса. В этой ситуации клиент фактически не может поддерживать блокировки базы данных, так как соединения берутся из пула, и вы не можете использовать одно и то же соединение для одного доступа к другому.
Пессимистическая блокировка - это когда вы блокируете запись для своего эксклюзивного использования до тех пор, пока не закончите с ней. Он имеет гораздо лучшую целостность, чем оптимистичная блокировка, но требует от вас осторожности при разработке приложения, чтобы избежать тупиковых ситуаций. Чтобы использовать пессимистическую блокировку, вам необходимо либо прямое соединение с базой данных (как это обычно бывает в двухуровневом клиент-серверном приложении), либо внешне доступный идентификатор транзакции, который можно использовать независимо от соединения.
В последнем случае вы открываете транзакцию с TxID, а затем повторно подключаетесь с использованием этого идентификатора. СУБД поддерживает блокировки и позволяет вам забрать сеанс обратно через TxID. Именно так работают распределенные транзакции, использующие протоколы двухфазной фиксации (такие как транзакции XA или COM +).
Изменить (добавив больше информации для решения вопроса производительности):
Производительность зависит от вашей среды. Примите во внимание следующие факторы:
вы найдете оптимизм лучше из-за параллелизма в большинстве ситуаций. Однако в зависимости от СУБД и среды это может быть менее или более производительным. Как правило, с Оптимистической блокировкой вы обнаружите, что значение должно быть где-то версировано.
Например, в MS SQL Server он перемещается в TempDB, и в конце столбца добавляется что-то между 12-14 байтами. Включение оптимистической блокировки с уровнем изоляции, таким как изоляция моментальных снимков, может привести к фрагментации, и необходимо будет скорректировать коэффициент заполнения, так как строки теперь имеют дополнительные данные в конце, что может привести к тому, что страница почти заполнится, что приведет к разделению страницы, что приведет к снижению ваше выступление. Если ваша TempDB недостаточно оптимизирована, это будет не так быстро.
Итак, я думаю, контрольный список:
- - Достаточно ли у вас ресурсов ввода-вывода / ресурсов для обработки версий версий строк? Если нет, вы добавляете накладные расходы. Если это так, то, если вы часто читаете данные, в то время как вы часто блокируете их для записи, вы заметите хорошее улучшение параллелизма между операциями чтения и записи (хотя операции записи по-прежнему блокируют записи, операции чтения больше не будут блокировать записи и наоборот)
- -Ваш код подвержен тупикам или у вас есть блокировка? Если вы не испытываете длительных блокировок или много взаимоблокировок, то дополнительные издержки Оптимистической блокировки не ускорят работу, конечно, в большинстве случаев мы говорим здесь за миллисекунды.
- -Если ваша БД большая (или на очень ограниченном оборудовании) и ваши страницы данных почти заполнены, в зависимости от СУБД, вы можете вызвать серьезные расщепления страниц и фрагментацию данных, поэтому обязательно включите переиндексацию после включения.
Это мои мысли по этому вопросу, открытые для получения дополнительной информации от сообщества.