основная проблема блокировки триггера

Question

У меня есть один вопрос относительно триггера. Сценарий таков

Create Procedure
begin
    Insert into XYZ (a) values (b)
end

Теперь я установил триггер на ВСТАВИТЬ - ПОСЛЕ в таблице XYZ. В этом триггере есть бизнес-логика, выполнение которой занимает 2-3 секунды, бизнес-логика выполняется для другой таблицы базы данных , а не для таблицы XYZ

Так что мне нужно подтвердить здесь, что после выполнения INSERT таблица XYZ будет готова выполнить вставку для других записей или будет заблокирована до завершения триггера?

EDIT

Я провел еще несколько исследований по этому вопросу и объясню его ниже. В INSERT - TRIGGER я поместил свою бизнес-логику и также ниже строки

WAITFOR DELAY '00:01'

Теперь, когда я пытаюсь выполнить вышеуказанный SP, SP не был завершен в течение 1 минуты (так как я указал задержку в 1 минуту в триггере), и таблица XYZ также была заблокирована в течение этого периода.

Таким образом, это приводит меня к выводу, что триггер блокирует таблицу, даже если вы не используете ту же таблицу в триггере. Я прав? У кого-нибудь здесь другое мнение?

Answer 1

Вопрос и ответ, связанные с @Hallainzil, показывают один подход:

• Обернуть все INSERT-таблицы и ОБНОВЛЕНИЯ в хранимые процедуры
• После этого SP может завершить дополнительную бизнес-логику безподдержание блокировки

Существует также другой подход, который несколько усложняется во многих отношениях, но также более гибок во многих отношениях:

• Вести учет полей, которые были ВСТАВЛЕНЫ или ОБНОВЛЕНЫ
• Иметь агентазадание запускается несколько раз или в одночасье для обработки этих изменений

Вы можете использовать триггер для сохранения этой записи.Может быть, с полем LastModifiedTime, полем hasBeenProcessed или даже с отдельной таблицей отслеживания.Это может быть сделано разными способами и относительно легок в обслуживании (пока не происходит никакой бизнес-логики).

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

Недостатком является то, что ваши INSERTS / UPDATES и ваша бизнес-логика обрабатываются асинхронно,Ваш другой код SQL, возможно, должен проверить, завершена ли или нет бизнес-логика, а не просто предполагать, что как INSERT, так и Business Logic всегда происходят атомарно.

Так что да, есть способы избежать этой блокировки.Но вы вводите дополнительные ограничения и / или сложность в вашу модель.Это ни в коем случае не плохо, но это необходимо учитывать в рамках вашего общего дизайна.