Какова связь между уровнями блокировки, блокировки и изоляции?

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

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

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

Я бы настоятельно рекомендовал прочитать прекрасную книгу Тома Кайта "Эксперт по архитектуре базы данных Oracle", в которой эти и другие темы освещены достаточно четко.

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

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

Это решение приложения, а не решение 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

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

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

Уровень изоляции SERIALIZABLE гораздо ближе к оптимистичному механизму блокировки. Будет выдано исключение, если транзакция попытается обновить запись, которая была обновлена ​​с момента начала транзакции. Однако он полагается на взаимное соответствие между сеансом базы данных и сеансом конечного пользователя.

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

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