Триггеры они асинхронные? - PullRequest
4 голосов
/ 17 июня 2010

У меня есть таблица A, в которой содержится общее количество пользователей в таблице B. Все, что меня волнует, - это то, что счет в таблице A синхронизируется с количеством пользователей в таблице B.

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

Существует два способа: - а) если я вставляю строку в таблицу B, я могу выдать счетчик обновлений в таблице A в одной хранимой процедуре.Этот результат в две команды вставки с последующим обновлением.Следовательно, скажем, займет 2 секунды.(при условии, что каждый txn в 1 секунду)

b) Я могу написать команду вставки в хранимую процедуру.Кроме того, определите триггер, который обновляет счет в таблице A после завершения вставки в таблицу A.Для меня это займет всего 1 секунду, что означает просто вставку строки в таблице B. Я предполагаю, что «триггер вставки», который обновляет счет в таблице B, происходит в фоновом режиме и, следовательно, является асинхронным или неблокировка.

Правильно ли это предположение или оба подхода займут одинаковое время.

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

Любые предложения / комментарии?

1 Ответ

8 голосов
/ 18 июня 2010

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

Если вы не хотите, чтобы он был синхронным, я полагаю, вы могли бы сделать его вставкой в ​​таблицу ожидающих изменений, а затем иметь асинхронный процесс, который обновляет его.Это, вероятно, позволило бы избежать многих взаимоблокировок в долгосрочной перспективе (вставка в таблицу без вторичных индексов не может привести к взаимоблокировке с другой вставкой в ​​ту же таблицу, AFAIK)

...