hi all.
Сначала - пример с INSERT'ами, три сеанса:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
session #1
SQL> recreate table test(id int constraint test_pk primary key);
SQL> commit;
SQL> set transaction snapshot table stability;
SQL> insert into test values(1);
SQL> -- возвращается в подсказку
session #2
SQL> commit; set transaction snapshot table stability;
SQL> insert into test values(2);
-- висит, и это для TIL = table stability - правильно
session #3
SQL> commit; set transaction snapshot table stability;
SQL> insert into test values(3);
-- тоже висит
session #1
SQL> COMMIT;
session #2 : возвращается в "SQL>" подсказку, т.е. ВЫПОЛНИЛА свой инсерт
session #3 : висит
session #2 : commit;
session #3 : возвращается в "SQL>" подсказку, т.е. тоже ВЫПОЛНИЛА свой инсерт.
А почему, соб-сно, сеансы 2 и 3 не обломались ? Ведь когда таблица была уже изменена транзакцией сеанса-1 (пусть еще и не закоммиченной), никакие другие транзакции с TIL = table stability *не* должны иметь возможности вносить изменения в эту таблицу.
Дока гласит:
langref30.pdf страница 431 ... после старта такой транзакции в других клиентских транзакциях невозможно выполнение изменений ни в каких таблицах этой базы данных. Все такие попытки в параллельных процессах приведут
к исключениям базы данных
Теперь - пример с UPDATE, тоже три сеанса (в предположении, что в таблице уже есть три строки, с id = 1, 2 & 3.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
session #1
SQL> commit;
SQL> set transaction snapshot table stability;
SQL> update test set id=-id where abs(id)=1;
SQL>
session #2
SQL> commit;
SQL> set transaction snapshot table stability;
SQL> update test set id=-id where abs(id)=2;
-- висит...
session #3
SQL> commit;
SQL> set transaction snapshot table stability;
SQL> update test set id=-id where abs(id)=3;
-- висит...
session #1
SQL> ROLLBACK;
session #2
-- немедленно получает... облом:
Statement failed, SQLSTATE = 40001
deadlock
-Acquire lock for relation (TEST) failed
SQL>
session #3
-- по прежнему висит, ожидая результата транзакции в сеансе #2.
Почему сеанс-2 получил облом после того, как сеанс-1 отменил свою транзакцию ?
