Ну, уровень изоляции и область действия - это две разные вещи.
Уровень изоляции
Триггеры действуют в рамках транзакции. По умолчанию эта транзакция должна использовать уровень изоляции по умолчанию READ COMMITTED. Однако, если вызывающий процесс указал другой уровень изоляции, то это переопределит значение по умолчанию. Как обычно: при желании вы можете переопределить это в самом триггере.
Согласно странице MSDN для DML Triggers:
Триггер и утверждение, что пожары ее рассматривают как одну транзакцию, который может быть произведен откат из триггера. Если обнаружена серьезная ошибка (например, недостаточное дисковое пространство), вся транзакция автоматически откатывается назад.
Область
Контекст предоставленный:
{от вас}
два пользователя, выполнение обновления к той же таблице --Но тех же строки
{из первой связанной статьи MSDN в Вопросе, которая является "по существу тем же самым вопросом, который я пытаюсь t o найти ответ на "}
Включены ли вставленные и удаленные таблицы в текущую сессию? Другими словами, они будут содержать только вставленные и удаленные записи для текущей области или будут содержать записи для всех текущих операций обновления по одной и той же таблице? Могут ли быть даже настоящие параллельные операции или блокировки предотвращают это?
Перед тем, как в таблицах inserted и deleted должно быть совершенно ясно, что там будет только когда будет одна операция DML происходит на конкретной строке в любой данный момент. Два или более запросов могут появиться на той же самой наносекунде, но все запросы будут проходить в очередь, по одному (и да, из-за блокировки).
Теперь о том, что в таблицах inserted и deleted: Да, только те строки, для этого конкретного события будут (и даже может быть) в этих двух псевдо-таблицах. Если вы выполните UPDATE, который изменит 5 строк, только те 5 строк будут в таблицах inserted и deleted. И поскольку вы ищете документацию, страница MSDN для Use the inserted and deleted Tables состояний:
Удаленной таблица хранится копия изменяемых строк во время удаления или обновления отчетности. Во время выполнения инструкции DELETE или UPDATE строки удаляются из таблицы триггеров и переносятся в удаленную таблицу. Удаленная таблица и таблица триггеров обычно не имеют рядов.
Вставленная таблица хранит копии затронутых строк во время инструкций INSERT и UPDATE. Во время транзакции вставки или обновления новые строки добавляются как в вставленную таблицу, так и в таблицу триггеров. Строки во вставленной таблице представляют собой копии новых строк в таблице триггеров.
Связывая это обратно к другой части вопроса, то часть, касающаяся уровне изоляции транзакций: Уровень изоляции транзакций не имеет абсолютно никакого влияния на таблицах inserted и deleted, как они относятся конкретно к этому событию/запросу. Однако чистый эффект этой операции, который фиксируется в этих двух psuedo-таблицах, по-прежнему может быть видимым другим процессам, если они используют уровень изоляции READ UNCOMMITTED или подсказку таблицы NOLOCK.
И как раз для того, чтобы прояснить что-то, страница MSDN, связанная выше в отношении таблиц inserted и deleted, в самом начале говорит о том, что они «в памяти», но это не совсем правильно. Начиная с SQL Server 2005 эти две псевдотаблицы фактически основаны на tempdb. На странице MSDN для tempdb Database состояний:
Tempdb системы базы данных является глобальным ресурсом, который доступен для всех пользователей, подключенных к экземпляру SQL Server и используется для хранения следующего:
......
Рядовые версии, которые генерируются транзакциями модификации данных для таких функций, как: операции онлайн-индекса, множественные активные наборы результатов (MARS) и триггеры AFTER.
До SQL Server 2005, то inserted и deleted столы были считаны из журнала операций (я считаю).
В итоге, inserted и deleted столы:
- работают в рамках транзакции
- являются статичными (т.е. только для чтения) таблицы
- видны только текущий триггер
- содержат только строки для конкретного события/операции/запроса, которые запускали этот экземпляр этого триггера
Да. 1 пользователь не сможет одновременно видеть данные от второго пользователя. Ну, конечно, предполагается, что триггер не использует read uncommitted или nolock. Это просто доказать самому себе. Создайте таблицу с триггером. Затем откройте 1 вкладку в SSMS и начните транзакцию и выполните вставку. Не совершайте транзакцию и делайте то же самое на второй вкладке. Вторая вкладка не может видеть незафиксированные данные из вкладки 1. –
Я не уверен, что вы найдете какую-либо официальную документацию, которая конкретно укажет это в том виде, который вы хотите. Но довольно легко представить себе, как хаотическое развитие триггеров было бы, если бы это было не так. –
@Damien_The_Unbeliever Есть некоторые официальные документы, с которыми я связан, которые дают кусочки этого. –