ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / set transaction snapshot table stability: не понимаю поведение сессий при DML
9 сообщений из 9, страница 1 из 1
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037408
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all.

Сначала - пример с INSERT'ами, три сеанса:

Код: plaintext
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>" подсказку, т.е. тоже ВЫПОЛНИЛА свой инсерт.

бНОПНЯ-1. А почему, соб-сно, сеансы 2 и 3 не обломались ? Ведь когда таблица была уже изменена транзакцией сеанса-1 (пусть еще и не закоммиченной), никакие другие транзакции с TIL = table stability *не* должны иметь возможности вносить изменения в эту таблицу.
Дока гласит:
langref30.pdf страница 431 ... после старта такой транзакции в других клиентских транзакциях невозможно выполнение изменений ни в каких таблицах этой базы данных. Все такие попытки в параллельных процессах приведут
к исключениям базы данных

Теперь - пример с UPDATE, тоже три сеанса (в предположении, что в таблице уже есть три строки, с id = 1, 2 & 3.

Код: plaintext
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. Почему сеанс-2 получил облом после того, как сеанс-1 отменил свою транзакцию ?
...
Рейтинг: 0 / 0
27.08.2015, 13:02
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037412
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

у тебя старая версия доки. Я по этому поводу что-то правил, по совету ДЕ. И до сих пор не уверен, что там всё правильно написано.
...
Рейтинг: 0 / 0
27.08.2015, 13:04
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037430
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денис,

вот что СЕЙЧАС сидит в доке (только что скачал):pg. 443 Уровень изолированности SNAPSHOT TABLE STABILITY
Уровень изоляции транзакции SNAPSHOT TABLE STABILITY позволяет, как и в случае
SNAPSHOT, также видеть только те изменения, фиксация которых произошла не
позднее момента старта этой транзакции. При этом после старта такой транзакции
в других клиентских транзакциях невозможно выполнение изменений ни в каких
таблицах этой базы данных, уже каким-либо образом измененных первой транзакцией.
Все такие попытки в параллельных транзакциях приведут к исключениям базы данных.
Просматривать любые данные другие транзакции могут совершенно свободно.
При помощи предложения резервирования (RESERVING) можно разрешить другим
транзакциям изменять данные в некоторых таблицах.
Если на момент старта клиентом транзакции с уровнем изоляции SNAPSHOT TABLE
STABILITY какая-нибудь другая транзакция выполнила неподтверждённое изменение
данных любой таблицы базы данных, то запуск транзакции с таким уровнем изоляции
приведёт к ошибке базы данных. Синенькое вызывает смутные сомнения (в том, что это утверждение истинно).
Красненькое вызывает тревогу: я НЕ вижу, чтобы сеансы 2 и 3 обламывались в стартах своих транзакций с этим TIL.
...
Рейтинг: 0 / 0
27.08.2015, 13:14
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037442
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоид,

да, красненькое неверно. без явного резервирования snapshot table stability конечно стартанет. Ошибка будет только при попытке доступа к уже заблокированной таблице.
И синенькое неверно. чего это вдруг просто старт транзакции без резервирования приведет к блокированию всех таблиц?
...
Рейтинг: 0 / 0
27.08.2015, 13:21
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037450
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
kdv,

там про всех и не написано.

автор уже каким-либо образом измененных первой транзакцией.
...
Рейтинг: 0 / 0
27.08.2015, 13:29
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037462
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvчего это вдруг просто старт транзакции без резервирования приведет к блокированию всех таблиц?гы... а с кляузой 'reserving' - вообще веселуха получается:

Код: plaintext
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.
30.
31.
32.
33.
34.
35.
36.
37.
session #1
SQL> recreate table test(id int constraint test_pk primary key);
SQL> commit;
SQL> set transaction snapshot table stability reserving test;

session #2
SQL> commit; set transaction snapshot table stability reserving test;
SQL> _
-- да! вернулось в подсказку без сообщения, что эта таблица уже задействована 
-- в другой r/w транзакции с TIL = table stability. Why ??

session #3
SQL> commit; set transaction snapshot table stability reserving test;
SQL> _
-- и эта тоже спокойно стартовала

session #1
SQL> insert into test values(1);
-- А вот тут случилось странное: эта команда зависла. 

session #2
SQL> insert into test values(2);

-- сначала повисело 10 сек, затем вывалило:
Statement failed, SQLSTATE = 40001
deadlock
-Acquire lock for relation (TEST) failed

session #3
SQL> insert into test values(3);

-- также сначала повисело 10 сек, затем вывалило:
Statement failed, SQLSTATE = 40001
deadlock
-Acquire lock for relation (TEST) failed

session #1
-- ПО ПРЕЖНЕМУ ВИСИТ, хотя стартовала самой первой!

Ы ?!
...
Рейтинг: 0 / 0
27.08.2015, 13:35
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037463
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоид
Код: plaintext
1.
session #1
-- ПО ПРЕЖНЕМУ ВИСИТ, хотя стартовала самой первой!
... и висела она так до тех пор, пока я не сделал COMMIT/ROLLBACK в сеансах 2 и 3. Такой вот high performance получился... :-/
...
Рейтинг: 0 / 0
27.08.2015, 13:37
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39037525
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоидset transaction snapshot table stability reserving test;
резервирование имеет 4 опции - shared_read, shared_write, protected_read, protected_write. Поскольку в "reserving test" вид резервирования не указан, то я предполагаю что там максимум shared_write, что дает возможность ДРУГИМ транзакциям stability reserving test стартовать.
Вот если начать указывать protected, тогда конкурирующие будут обламываться при старте.

Вопрос этот сложный, как минимум, процитирую себя
www.ibase.ru/devinfo/ibtrans.htm Резервирование таблиц.
"Есть еще один интересный момент. Проверяя режимы транзакций я обнаружил, что если одна транзакция consistency блокирует таблицу в режиме shared_write, то другая транзакция consistency при попытке открыть таблицу в режиме shared_read "повиснет" (именно в момент открытия таблицы). В то же время попытка открыть эту же таблицу в режиме shared_write завершается полным успехом."

Симонов Денистам про всех и не написано.
да, виноват, невнимательно прочитал. в "синеньком" вроде все норм.
...
Рейтинг: 0 / 0
27.08.2015, 14:25
| Ответить | Цитировать | Написать  
set transaction snapshot table stability: не понимаю поведение сессий при DML
    #39038853
Кузнецов Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кузнецов Евгений
Гость
kdvВопрос этот сложный, как минимум, процитирую себя...
8 лет назад пытался в этом разобраться, да так и не довел до конца - тынц .
Там сошлись, что статья не совсем верна, но уже не помню, в чем именно :)
...
Рейтинг: 0 / 0
28.08.2015, 20:01
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / set transaction snapshot table stability: не понимаю поведение сессий при DML
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=72&tid=1562654]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 32ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 55ms
get tp. blocked users:
 2ms
others: 304ms
total:  435ms
созд. / загр.: 435ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]