Зачем нам нужно блокирование намерений?

Question

В базе данных нам не хотелось бы, чтобы таблица была удалена во время изменения строки в этой таблице. По моему пониманию, блокировка чтения на таблице + блокировка записи в строке при записи строки в таблице должна быть достаточной (на основании того, что при удалении таблицы требуется блокировка записи), зачем в этом случае нужна блокировка намерений? кажется, много баз данных, использующих блокировку намерений, которые меня очень смутили. Я думаю, что pthread_rwlock должно быть достаточно.

Answer 1

блокировки чтения на столе + блокировка записи по строке

Это нарушило бы смысл read lock на столе.

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

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

IX(Intent eXclusive) on table + X(eXclusive, similar to "write lock") on row 

Эта комбинация совместима (то есть, может быть выполнена параллельно) с модификацией другого ряда, но это несовместима с

S(Share, similar to "read lock") on table 

используется SELECT.

Таблица совместимости замков может быть найдена, например, на wiki.

Answer 2

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

Heres цитата из блога:

С технической точки зрения Намерение замки не очень необходимой SQL Server. Они связаны с оптимизацией производительности. Давайте посмотрим на это более подробно. С помощью Intent Lock SQL Server только указывает на более высоком уровне в иерархии блокировки, которую у вас есть , и приобрел замок где-то в другом месте. Intent Shared Lock сообщает SQL Server , что в другом месте есть общий замок. Интенсивное обновление или намерение Исключительная блокировка делает то же самое, но на этот раз SQL Server знает, что есть блокировка обновления или эксклюзивный замок где-то. Это всего лишь показатель , не более того.

Но как это указание помогает SQL Server с производительностью ? Представьте, что вы хотите приобрести эксклюзивный замок на уровне стола . В этом случае SQL Server должен знать, есть ли в записи несовместимый замок (например, Shared или Update Lock) в записи . Без блокировок Intent SQL Server должен будет проверить каждую запись , чтобы узнать, предоставлен ли несовместимый замок.

Но с Intent разделяемой блокировкой на уровне таблицы, SQL Server знает сразу, что разделяемая блокировка была предоставлена ​​где-то еще, и поэтому монопольная блокировка не может быть предоставлена ​​на уровне таблицы. В этом вся причина, по которой Intent Locks существуют в SQL Server: разрешить эффективную проверку, существует ли какая-либо несовместимая блокировка в пределах Иерархия блокировки. Довольно легко, не так ли?