Как механизмы блокировки (Пессимистический/Оптимистический) связаны с уровнями изоляции транзакций базы данных?

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

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

Как эти две разные концепции связаны друг с другом? Если возможно, простейшим примером.

Ответы

Ответ 1

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

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

Изоляция транзакций - это согласованность чтения.

  • Чтение незафиксированного уровня позволяет сеансу видеть другие незафиксированные изменения сеанса.
  • Чтение зафиксированного уровня позволяет сеансу видеть, что другие сеансы зафиксировали изменения только
  • Сериализуемый уровень позволяет сеансу видеть только изменения, совершенные до начала транзакции.

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

SESSION 1                                  SESSION 2
--------------------------------           --------------------------------------
SELECT count(*) FROM test;
=> 10
                                           INSERT INTO test VALUES ('x');

SELECT count(*) FROM test;
=> 10 with read committed/serializable
=> 11 with read uncommited (dirty read)
                                           COMMIT;

SELECT count(*) FROM test;
=> 10 with serializable
=> 11 with read uncommitted/read committed

Существует четыре уровня изоляции транзакций по ANSI (один из них не упоминается в примере выше, это "повторяемое чтение" ), все из них, кроме сериализуемых, подвержены некоторым аномалиям. Обратите внимание, что это не имеет никакого отношения к блокировке.

Вы можете взглянуть на документацию Oracle на этот здесь, концепции довольно универсальны.

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

Ответ 2

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

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

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

Мой совет от пятнадцатилетней разработки бизнес-приложений не должен полагаться на явную блокировку.