KEY VIOLATION при выполнении процедуры.

← →
Petr V. Abramov (2004-01-21 20:28) [40]

> Vuk © (21.01.04 18:40) [37]
> Бр-р-р-р.... Проверку if exists имеет смысл делать в любом
> случае.
Проводим эксперимент:
create table t1 ( f1 integer, primary key(f1))
create procedure brrr as
begin
if (exists (select 1 from t1 where f1 = 1)) then
exception some_exception;
end;

Запускаем 2 транзакции, А и B, обе read_commited rec_version
20:06 Transaction A
insert into t1 values(1)
20:07 Transaction B
execute procedure brrr -- все тихо
20:08 Transaction A
commit
20:09 Transaction B
execute procedure brrr -- поднимается исключение

если, как советует jack128 ©, использовать no_rec_version, транзакция B подождет завершения A, чтобы определиться, "exists" или "не exists". Но no_rec_version - это не развязанные чтение с записью, со всеми прелестями

← →
Vuk (2004-01-21 22:30) [41]

to Petr V. Abramov:
>Проводим эксперимент
Еще раз повторяю. Проверка нужна, иначе получим Key Violation при вставке, если запись существовала уже тогда, когда еще не стартовали все существующие транзакции.

no_rec_version - не пойдет, т.к. в этом случае не пройдет даже чтение. Уж если на то пошло, то лучше SNAPSHOT TABLE STABILITY.

← →
Petr V. Abramov (2004-01-21 22:59) [42]

> Vuk © (21.01.04 22:30) [41]
> no_rec_version - не пойдет, т.к. в этом случае не пройдет даже
> чтение.
Еще как пройдет, если транзакция не nowait. Но будет ждать.
> Проверка нужна, иначе получим Key Violation при вставке, если
> запись существовала уже тогда, когда еще не стартовали все
> существующие транзакции.
Эта проверка уменьшит вероятность появления Key Violation. За счет проверки частного случая, когда существует закоммиченная запись с заданным ключом (извиняюсь за перефразирование :) Если конкуренция за ресурс небольшая - даже решит проблему. Но на 99.9%, не на 100%
Да и вообще зачем писать самому то, что реализовано на уровне СУБД, в данном случае проверку уникальности??? Да, схема insert -> when KEY_VIOLATION -> update работает (чаще всего) медленне, чем update -> if notfound -> insert (которую мы не можем реализовать из-за ограничений языка). Но я уверен, что быстрее, чем ручная проверка уникальности ключа (которая и срабатывает только на "вчерашние" записи)

← →
Vuk (2004-01-21 23:12) [43]

to Petr V. Abramov:
>Но я уверен, что быстрее, чем ручная проверка уникальности ключа
Тут ссылочки приводили. Там замеряли производительность. Схема с WHEN не просто медленная, а самая медленная во всех случаях. Там же приведен весьма неплохой вариант с курсором.

← →
jack128 (2004-01-21 23:14) [44]

> чем update -> if notfound -> insert (которую мы не можем
> реализовать из-за ограничений языка).
Почему не можем, все можем, если с IB на FB переползем(см выше про row_count) ;-)

← →
Petr V. Abramov (2004-01-22 16:28) [45]

KEY VIOLATION при выполнении процедуры. Найти похожие ветки