|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Если Вы блокируете таблицу явно с LOCK
TABLES, любые таблицы, используемые в триггерах, также блокируются неявно:
Блокировки берутся в качестве того же самого времени как полученные явно с LOCK TABLES
оператор.
Блокировка на таблице, используемой в триггере, зависит от того, используется ли таблица только для того, чтобы читать. Если так, блокировка чтения достаточна. Иначе, блокировка записи используется.
Если таблица блокируется явно для того, чтобы читать с LOCK TABLES, но потребности, которые будут заблокированы для того, чтобы
записать, потому что это могло бы быть изменено в пределах триггера, блокировка записи, берутся, а не
блокировка чтения. (Таким образом, неявная блокировка записи, необходимая из-за появления таблицы в
пределах триггера, заставляет явный запрос блокировки чтения на таблицу быть преобразованным в запрос
блокировки записи.)
Предположите, что Вы блокируете две таблицы, t1 и t2,
использование этого оператора:
LOCK TABLES t1 WRITE, t2 READ;
Если t1 или t2 имейте любые триггеры, таблицы,
используемые в пределах триггеров, будут также заблокированы. Предположите это t1
определили триггер как это:
CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROWBEGIN UPDATE t4 SET count = count+1 WHERE id = NEW.id AND EXISTS (SELECT a FROM t3); INSERT INTO t2 VALUES(1, 2);END;
Результат LOCK TABLES
оператор - это t1 и t2 блокируются, потому что они
появляются в операторе, и t3 и t4 блокируются, потому
что они используются в пределах триггера:
t1 блокируется для того, чтобы записать на WRITE запрос блокировки.
t2 блокируется для того, чтобы записать, даже при том,
что запрос для a READ блокировка. Это происходит потому что t2 вставляется в в пределах триггера, таким образом, READ запрос преобразовывается в a WRITE
запрос.
t3 блокируется для того, чтобы читать, потому что это
только читается изнутри триггера.
t4 блокируется для того, чтобы записать, потому что это
могло бы быть обновлено в пределах триггера.