Я понимаю разницу между оптимистической и пессимистической блокировкой. Может ли кто-нибудь объяснить мне, когда я буду использовать один из них вообще?
И меняется ли ответ на этот вопрос в зависимости от того, использую ли я хранимую процедуру для выполнения запроса?
Но просто для проверки оптимистический означает "не блокировать таблицу во время чтения", а пессимистический означает "заблокировать таблицу во время чтения".
Оптимистическая блокировка - это стратегия, в которой вы читаете запись, обратите внимание на номер версии (другие методы для этого включают даты, временные метки или контрольные суммы/хэши) и убедитесь, что версия не изменилась, прежде чем вы записываете запись. Когда вы записываете запись, вы фильтруете обновление в версии, чтобы убедиться, что оно атомарно. (т.е. не обновлялся между тем, когда вы проверяете версию и записываете запись на диск) и обновляйте версию за один раз.
Если запись загрязнена (т.е. другая версия для вас), вы прерываете транзакцию, и пользователь может ее повторно запустить.
Эта стратегия наиболее применима к системам с большими объемами и трехуровневыми архитектурами, где вы не обязательно поддерживаете соединение с базой данных для своей сессии. В этой ситуации клиент не может фактически поддерживать блокировки базы данных, поскольку соединения берутся из пула, и вы не можете использовать одно и то же соединение из одного доступа к следующему.
Пессимистическая блокировка - это когда вы блокируете запись для своего эксклюзивного использования, пока не закончите с ней. Он имеет гораздо лучшую целостность, чем оптимистическая блокировка, но требует, чтобы вы были осторожны с вашим дизайном приложения, чтобы избежать Deadlocks. Для использования пессимистической блокировки вам необходимо либо прямое подключение к базе данных (как это обычно бывает в двухуровневом клиентском сервере) или внешнем доступный идентификатор транзакции, который может использоваться независимо от соединения.
В последнем случае вы открываете транзакцию с TxID, а затем повторно соединяете с использованием этого идентификатора. СУБД поддерживает блокировки и позволяет вам выбрать сеанс обратно через TxID. Так распределены транзакции с использованием двухфазных протоколов фиксации (например, XA или COM + транзакции).
Оптимистическая блокировка используется, когда вы не ожидаете много столкновений. Обычная операция обходится дешевле, но если коллизия ДЕЙСТВИТЕЛЬНО произойдет, вы заплатите более высокую цену за ее разрешение при отмене транзакции.
Пессимистическая блокировка используется, когда ожидается коллизия. Транзакции, которые нарушают синхронизацию, просто блокируются.
Чтобы выбрать правильный механизм блокировки, вы должны оценить количество операций чтения и записи и составить соответствующий план.
Пессимистический предполагает, что что-то будет и так блокирует его.
Если не важно, чтобы данные были полностью прочитаны, используйте оптимистичный. Вы можете получить нечетное "грязное" чтение - но это гораздо менее вероятно приведет к взаимоблокировкам и т.д.
Большинство веб-приложений отлично справляются с грязными чтениями - в редких случаях данные не точно совпадают с следующей перезагрузкой.
Для точных операций с данными (как и во многих финансовых транзакциях) пессимистично. Очень важно, чтобы данные были точно прочитаны, без каких-либо изменений - лишние затраты на блокировку стоят того.
О, и сервер Microsoft SQL по умолчанию блокирует блокировку страницы - в основном, строку, которую вы читаете, и несколько сторон. Блокировка строк более точная, но намного медленнее. Часто стоит устанавливать транзакции на чтение или блокировку, чтобы избежать блокировок при чтении.
В дополнение к уже сказанному следует сказать, что оптимистичная блокировка имеет тенденцию улучшать concurrency за счет предсказуемости. Пессимистическая блокировка имеет тенденцию уменьшать concurrency, но более предсказуема.
Вы платите свои деньги и т.д.
Я бы подумал о еще одном случае, когда пессимистическая блокировка была бы лучшим выбором.
Для оптимистической блокировки каждый участник модификации данных должен согласиться с использованием такого типа блокировки. Но если кто-то изменяет данные, не заботясь о столбце версии, это испортит всю идею оптимистической блокировки.
Есть в основном два самых популярных ответа. Первый в основном говорит
Для Optimistic требуется трехуровневая архитектура, в которой вы не обязательно поддерживаете соединение с базой данных для своего сеанса, тогда как Pessimistic Locking - это когда вы блокируете запись для своего эксклюзивного использования до тех пор, пока не закончите с ней. У него гораздо лучшая целостность, чем у оптимистической блокировки, вам нужно либо прямое соединение с базой данных.
Оптимистическое (управление версиями) быстрее из-за отсутствия блокировок, но (пессимистическое) блокирование работает лучше, когда конкуренция высока, и лучше предотвращать работу, чем отбрасывать ее и начинать заново.
или же
Оптимистическая блокировка работает лучше всего при редких столкновениях
Как это написано на этой странице.
Я создал свой ответ, чтобы объяснить, как "сохранить соединение" связано с "низкими коллизиями".
Чтобы понять, какая стратегия лучше для вас, подумайте не о транзакциях в секунду, которые имеет ваша БД, а о продолжительности одной транзакции. Обычно вы открываете trasnaction, Performa Operation и закрываете транзакцию. Это короткая, классическая транзакция, которую ANSI имела в виду, и она прекрасно подходит для блокировки. Но как реализовать систему бронирования билетов, когда многие клиенты бронируют одни и те же номера/места одновременно?
Вы просматриваете предложения, заполняете форму множеством доступных опций и актуальными ценами. Это занимает много времени, и варианты могут устареть, все недействительные цены между вами начали заполнять форму и нажать кнопку "Я согласен", потому что не было блокировки данных, к которым вы обращались, и кто-то другой, более проворный, вмешался меняются все цены и вам нужно перезапустить с новыми ценами.
Вместо этого вы можете заблокировать все параметры по мере их чтения. Это пессимистичный сценарий. Вы видите, почему это отстой. Ваша система может быть отключена одним клоуном, который просто начинает бронирование и курит. Никто не может зарезервировать что-либо, прежде чем он закончит. Ваш денежный поток падает до нуля. Вот почему оптимистические оговорки используются в реальности. Те, кто слишком долго бездельничает, должны возобновить бронирование по более высоким ценам.
При таком оптимистичном подходе вы должны записать все данные, которые вы прочитали (как в моем повторном чтении), и прийти к точке фиксации с вашей версией данных (я хочу покупать акции по цене, указанной в этой цитате, а не по текущей цене).). На этом этапе создается транзакция ANSI, которая блокирует БД, проверяет, ничего не изменилось и фиксирует/прерывает вашу операцию. IMO, это эффективная эмуляция MVCC, которая также связана с Optimistic CC и также предполагает, что ваша транзакция перезапускается в случае сбоя, то есть вы сделаете новое резервирование. Транзакция здесь включает в себя решения пользователя.
Я далек от понимания того, как реализовать MVCC вручную, но я думаю, что длительные транзакции с возможностью перезапуска - ключ к пониманию предмета. Поправь меня, если я где-нибудь ошибаюсь. Мой ответ был мотивирован этой главой Алексея Кузнецова.
В большинстве случаев оптимистичная блокировка более эффективна и обеспечивает более высокую производительность. Выбирая между пессимистичной и оптимистичной блокировкой, рассмотрите следующее:
Пессимистическая блокировка полезна, если есть много обновлений и относительно высокие шансы пользователей, пытающихся обновить данные на одном и том же время. Например, если каждая операция может обновлять большое количество (банк может добавлять процентные доходы к каждому счет в конце каждого месяца), и запускаются два приложения такие операции в то же время, у них будут конфликты.
Пессимистическая блокировка также более подходит для приложений, содержащих небольшие таблицы, которые часто обновляются. В случае с этими так называемыми "горячими точками" конфликты настолько вероятны, что оптимистичная блокировка тратит усилия на откат противоречивых транзакций.
Оптимистическая блокировка полезна, если возможность конфликтов очень низкий - существует много записей, но относительно мало пользователей, или очень мало обновлений и в основном операций чтения.
Одним из вариантов использования оптимистической блокировки является то, чтобы ваше приложение использовало базу данных, чтобы один из ваших потоков/хостов "требовал" задачи. Это метод, который мне пригодится на регулярной основе.
Лучший пример, который я могу придумать, - это очередь задач, реализованная с использованием базы данных, с несколькими потоками, требующими одновременных задач. Если задание имеет статус "Доступно", "Заявлено", "Завершено", запрос db может сказать что-то вроде "Установить статус =" Заявлено ", где status =" Доступно ". Если несколько потоков пытаются изменить статус таким образом, все, кроме первого потока, будут терпеть неудачу из-за грязных данных.
Обратите внимание, что это прецедент, включающий только оптимистическую блокировку. Таким образом, в качестве альтернативы высказыванию "Оптимистическая блокировка используется, когда вы не ожидаете многих коллизий", ее также можно использовать там, где вы ожидаете коллизий, но хотите добиться успеха только одной транзакции.