Как соотносятся уровни блокировки, блокировки и изоляции?

Question

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

Я понимаю концепцию пессимистической и оптимистической блокировки, а также типичные примеры из банковского учебника о потере обновлений и т. Д.

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

Я немного неясен относительно того, как эти понятия связаны и взаимодействуют. Например:

• Предоставляет ли Oracle пессимистичный или оптимистическая блокировка по умолчанию (это просто кажется, чтобы заблокировать отдельный обновление на основе экспериментов в двух Сеансы TOAD.)
• Если, как я подозреваю, это концепции уровня приложения, почему бы Я иду на проблему реализации стратегия блокировки, когда я могу позволить база данных синхронизирует транзакцию все равно обновления?
• Как уровни изоляции транзакций (которые я установил для соединения) изменяют поведение базы данных, когда другие клиенты, кроме моего приложения, получают доступ с различными уровнями изоляции.

Любые слова, чтобы прояснить эти темы будут очень признательны!

Answer 1

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

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

• Обычно вам не нужно беспокоиться об этом.В Oracle читатели никогда не блокируют писателей, а писатели никогда не блокируют читателей.Поведение Oracle не меняется с различными уровнями изоляции ANSI.Например, в Oracle нет такого понятия, как «грязное чтение».Том Кайт отмечает, что принцип «грязного» чтения заключается в том, чтобы избегать блокирования операций чтения, что не является проблемой в Oracle.

Я настоятельно рекомендую прочитать превосходную книгу Тома Кита «База данных экспертов OracleАрхитектура », в которой эти и другие темы рассматриваются достаточно четко.

Answer 2

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

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

Это решение приложения,не решение Oracle, как:

ВЫБРАТЬ x, y, z ИЗ таблицы1 ГДЕ a = 2

не будет блокировать совпадающие записи, но

ВЫБРАТЬ x, y, z ОТtable1 ГДЕ a = 2 ДЛЯ ОБНОВЛЕНИЯ

будет.Поэтому вы должны решить, в порядке ли вы с оптимистической блокировкой

SELECT x, y, z FROM table1 WHERE a = 2

... проходит время ...

UPDATE table1
   SET x = 1, y = 2, z = 3
 WHERE a = 2

(вы могли бы отменить изменение, внесенное кем-то другим втем временем)

или нужно быть пессимистичным:

SELECT x, y, z FROM table1 WHERE a = 2 FOR UPDATE

... проходит время ...

UPDATE table1
   SET x = 1, y = 2, z = 3
 WHERE a = 2

(вы уверены, что ни у кого нетизменил данные, так как вы их запросили.)

Проверьте здесь уровни изоляции, доступные в Oracle.http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#CNCPT621

Answer 3

Oracle ВСЕГДА обрабатывает пессимистическую блокировку. Таким образом, он будет блокировать запись при ее обновлении (и вы также можете нажать блокировки для удалений и вставок, если задействован ключ). Вы можете использовать SELECT .... FOR UPDATE для улучшения стратегии пессимистической блокировки.

Действительно, любая база данных / механизм хранения, работающий транзакционно, должна выполнять некоторую форму блокировки.

СЕРИАЛИЗИРУЕМЫЙ уровень изоляции намного ближе к оптимистическому механизму блокировки. Будет выдано исключение, если транзакция попытается обновить запись, которая была обновлена ​​с начала транзакции. Однако между сеансом базы данных и сеансом конечного пользователя он зависит один на один.

По мере того как приложения с пулами соединений / без сохранения состояния становятся распространенными, особенно в системах с высокой активностью пользователей, сессия базы данных, связанная с длительным периодом, может быть плохой стратегией. Оптимистическая блокировка предпочтительна, и более поздние версии Oracle поддерживают это с элементами ORA_ROWSCN и ROWDEPENDENCIES. По сути, они позволяют легче увидеть, изменилась ли запись с тех пор, как вы в первый / последний раз смотрели ее.

Поскольку отношения один-к-одному между сеансом базы данных и сеансом пользователя стали устаревшими, прикладной уровень сохранил больше состояния «сеанса пользователя» и, таким образом, стал более ответственным за проверку выбора, сделанного пользователем пять / десять минут назад все еще в силе (например, книга еще в наличии или кто-то другой купил ее).