46. Протокол установки замков для дерева.

http://www.cs.ucsb.edu/~agrawal/spring2011/grad/Lecture7.pdf, стр. 19

Слайды: 4-consistency, стр. 22-23

молина, стр. 924 (на самом деле, там протокол немного отличается от того, что рассказывал Новиков. Например, в Молине первым без всяких адских требований можно захватывать любую вершину дерева, а не только корень. И там корректность труднее доказывается).

4.3.5 конспект

47. Мультигранулярные замки.

http://msdn.microsoft.com/en-us/library/ms175519.aspx

Слайды: 4-consistency, стр. 25-26

Молина, стр. 919

http://serversql.ru/upravlenie-parallelnoj-rabotoj/rezhimy-blokirovki.html - на русском

48. Уровни изоляции в sql и оптимистические замки.

конспект, стр. 51, 52

4-consistency, слайд 26, 28, 29, 32

Уровни изоляции

http://ru.wikipedia.org/wiki/Уровень%20изолированности%20транзакций

В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций. Уровни описаны в порядке увеличения изоляции транзакций и надёжности работы с данными.

• 0 — Неподтверждённое чтение (Read Uncommitted, Dirty Read, грязное чтение) — чтение незафиксированных изменений своей транзакции и конкурирующих транзакций, возможны нечистые, неповторяемые чтения и фантомы

• 1 — Подтверждённое чтение (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений конкурирующих транзакций, нечистые чтения невозможны, возможны неповторяемые чтения и фантомы

• 2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые конкурирующими транзакциями после начала своей, недоступны, нечистые и неповторяемые чтения невозможны, возможны фантомы

• 3 — Упорядоченный — (Serializable, сериализуемый) — упорядоченные (сериализуемые) транзакции. Идентичен ситуации, при которой транзакции выполняются строго последовательно, одна после другой. То есть транзакции, результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных, изменённых с начала транзакции, в том числе и своей транзакцией). Фантомы невозможны.

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать.

В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

http://www.t-sql.ru/post/nolock.aspx - много кода про уровни изоляции

Optimistic locking (оптимистическая блокировка)

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

Пользователь - существо загадочное и может очень долго заполнять и исправлять поля веб формы. Ничто ему не помешает в перерыве попить кофе или сходить в ресторан. Естесственно за это время другой расторопный пользователь может исправить теже самые данные и они окажутся уже неактуальными на тот момент, когда первый вернется из кафе и нажмет кнопку submit.

Программист полон оптимизма и справедливо рассчитывает на то что пользователь очень сделает все что от него требуется и закончит работу. Но в жизни не всегда так получается. В результате первый пользователь увидит на экране сообщение об ошибке а программист прочитает в логе Optimistic locking exception.

Таким образом если отойти от лирического вступления стратегия «Optimistic locking» предполагает, что никто не изменит данные в базе данных кроме Вас, поэтому нет необходимости блокировать эти данные на время работы всего приложения.