Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 15   вперед  Ctrl
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

PgSQLAnonymous
Хм, а разве нет (я напомню, мы обсуждаем вариант "происходит
повисание по wait с ожиданием результата")?

Ну это ты мне скажи: "да, я именно это утверждаю" или "нет, я утверждаю совсем другое".
Мой телепатер не справляется это угадать.

Posted via ActualForum NNTP Server 1.5

14 май 15, 17:45    [17641271]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
этта
в данном случае теряется возможность работать с записью. т.е. блокируется
запись.

этта
-- ах, да , я-то про версию -- читать
то что можно читать старую версию -- это естественно (её ж никто не лочил в
версионнике)

Ты этта... Определись что ли, блокируется таки запись или версия. Это как бэ не одно и тоже...

тебе написали уже -- запись блокируется "на запись".
ресурс для записи недоступен.

когда я говорю SELECT ...FOR UPDATE -- я блокирую запись
на запись
но читать её я могу сколько угодно.

Сообщение было отредактировано: 15 май 15, 00:23
14 май 15, 18:30    [17641482]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Хм, а разве нет (я напомню, мы обсуждаем вариант "происходит
повисание по wait с ожиданием результата")?

Ну это ты мне скажи: "да, я именно это утверждаю" или "нет, я утверждаю совсем другое".
Мой телепатер не справляется это угадать.

Я утверждаю, что подчёркнутое --- это блокировка:

Dimitry Sibiryakov
update обломится с ошибкой "update conflict" либо сразу, либо после коммита первой транзакции в зависимости от параметров транзакции


То впечатление, что в InterBase "второй/третий/четвёртый писатель будут ждать события освобождения записи", я вынес из постов в этой теме.
14 май 15, 19:23    [17641646]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

PgSQLAnonymous
Я утверждаю, что подчёркнутое --- это блокировка:

Ну тогда привет, КО, открывший для себя, что даже в версионниках писатели блокируют писателей.

Posted via ActualForum NNTP Server 1.5

14 май 15, 19:32    [17641680]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

Dimitry Sibiryakov
после коммита первой транзакции

PgSQLAnonymous
То впечатление, что в InterBase "второй/третий/четвёртый писатель
будут ждать события освобождения записи", я вынес из постов в этой теме.

Хреновый у тебя выноситель впечатления, если он из слов "после коммита транзакции" вынес
"событие освобождения записи", ибо это две большие разницы.

Posted via ActualForum NNTP Server 1.5

14 май 15, 19:56    [17641747]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
Dimitry Sibiryakov
<>
Хреновый у тебя выноситель впечатления, если он из слов "после коммита транзакции" вынес
"событие освобождения записи", ибо это две большие разницы.
ну при роллбеке же она таки освободится

а при коммите -- будет негодна из-за кривого базового уровня изоляции. освободится проброс исключений, а не запись-пись

а вот при человеческом рид--коммитеде была бы годна в дело, но здесь вам не тут...то было.


Сообщение было отредактировано: 15 май 15, 00:22
14 май 15, 20:14    [17641812]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

этта
ну при роллбеке же она таки освободится

Запись, вообще-то, может освободиться (то есть исчезнет незакоммиченная версия) задолго до
конца транзакции.

этта
освободится проброс исключений, а не запись-пись

Чо?

Posted via ActualForum NNTP Server 1.5

14 май 15, 20:18    [17641827]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
PgSQLAnonymous
Я утверждаю, что подчёркнутое --- это блокировка:

Ну тогда привет, КО, открывший для себя, что даже в версионниках писатели блокируют писателей.


Надо же, а в теме я вот уже успел вычитать, что:

kdv
я не знаю, как там у PosgreSQL, но у InterBase и Firebird нет никаких "блокировок для UPDATE".


kdv
То есть, как таковых блокировок в версионнике нет вообще. Есть единственный конфликт - конфликт обновления одной и той же записи из двух активных транзакций. Причем, устанавливать какую-то там "блокировку" для этого случая нет необходимости. Новая версия записи, созданная первой транзакцией, и есть этот самый "индикатор блокировки".


Видно, не все это ещё открыли для себя. ;)
14 май 15, 20:58    [17641972]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
Dimitry Sibiryakov
Dimitry Sibiryakov
после коммита первой транзакции

PgSQLAnonymous
То впечатление, что в InterBase "второй/третий/четвёртый писатель
будут ждать события освобождения записи", я вынес из постов в этой теме.

Хреновый у тебя выноситель впечатления, если он из слов "после коммита транзакции" вынес
"событие освобождения записи", ибо это две большие разницы.

Честно говоря, после того, как я прочитал про InterBase и увидел какие-то странные уровни изоляции
и отсутствие SERIALIZABLE, разбираться в его особенностях мне стало как-то неинтересно...
14 май 15, 21:09    [17642007]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
PgSQLAnonymous
странные уровни изоляции

например?

PgSQLAnonymous
отсутствие SERIALIZABLE

а кому-нибудь в жизни потом эта туфля пригодилась? (с)
15 май 15, 01:07    [17642754]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
dimitr
а кому-нибудь в жизни потом эта туфля пригодилась? (с)
Тем более, что она есть.
15 май 15, 01:09    [17642756]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
dimitr
PgSQLAnonymous
странные уровни изоляции

например?

PgSQLAnonymous
отсутствие SERIALIZABLE

а кому-нибудь в жизни потом эта туфля пригодилась? (с)

только эта туфля и рабочая
15 май 15, 03:23    [17642819]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
dimitr
PgSQLAnonymous
странные уровни изоляции

например?

READ COMMITTED RECORD_VERSION
READ COMMITTED NO RECORD_VERSION
SNAPSHOT
SNAPSHOT TABLE STABILITY

dimitr
PgSQLAnonymous
отсутствие SERIALIZABLE

а кому-нибудь в жизни потом эта туфля пригодилась? (с)

Естественно.
15 май 15, 08:23    [17643025]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
dimitr
а кому-нибудь в жизни потом эта туфля пригодилась? (с)
Тем более, что она есть.

Как-то не заметил, можете показать?
15 май 15, 08:24    [17643028]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
PgSQLAnonymous
hvlad
Тем более, что она есть.

Как-то не заметил, можете показать?
SNAPSHOT TABLE STABILITY
15 май 15, 09:28    [17643224]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
PgSQLAnonymous
странные уровни изоляции
...
SNAPSHOT

какой тонкий троллинг...
15 май 15, 09:37    [17643266]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
hvlad
SNAPSHOT TABLE STABILITY

ну, справедливости ради, это скорее инструмент для ручной эмуляции SERIALIZABLE. Кому надо автоматически да для ad-hoc запросов, то в сад.
15 май 15, 09:49    [17643329]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
dimitr
hvlad
SNAPSHOT TABLE STABILITY

ну, справедливости ради, это скорее инструмент для ручной эмуляции SERIALIZABLE. Кому надо автоматически да для ad-hoc запросов, то в сад.
Ты говоришь о явном резервировании таблиц.
Которое указывается в предложении RESERVING.
А SNAPSHOT TABLE STABILITY как раз и есть автоматическое резервирование таблицы по ходу выполнения DML.

В Борландовской документации это описано вот так:
ApiGuide
isc_tpb_consistency Table-locking transaction model. This mode is serializable.
isc_tpb_consistency - это и есть SNAPSHOT TABLE STABILITY
15 май 15, 10:16    [17643452]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
PgSQLAnonymous
пропущено...
Как-то не заметил, можете показать?
SNAPSHOT TABLE STABILITY

Вот тут я прямо заинтересовался. Доказательства-то этому есть?

+

Вы можете показать, что будет, если сделать примерно так:
-- Подготовка
-- Таблицы, чтобы взять SNAPSHOT-ы.
-- Они нужны, если в InterBase SNAPSHOT начинается не с BEGIN TRANSACTION,
-- а с первого запроса (как во многих других СУБД).
CREATE TABLE N1(n INT)
INSERT INTO N1 VALUES(1)
CREATE TABLE N2(n INT)
INSERT INTO N2 VALUES(1)
-- Нужные таблицы:
CREATE TABLE A(n INT)
INSERT INTO A VALUES(0)
CREATE TABLE B(n INT)
INSERT INTO B VALUES(0)
-- Теперь две сессии, T1 и T2.
-- В каждой нужно установить уровень изоляции SNAPSHOT TABLE STABILITY так,
-- чтобы он действовал в дальнейших транзакциях, или же устанавливать его
-- внутри каждой транзакции (не знаю, как в InterBase делается)
----------------------------------------------
-- Далее тест:
-- T1:
BEGIN TRANSACTION
SELECT * FROM N1
-- T2:
BEGIN TRANSACTION
SELECT * FROM N2
-- T1:
INSERT INTO B
SELECT COUNT(*)
  FROM A
COMMIT
-- T2:
INSERT INTO A
SELECT COUNT(*)
  FROM B
COMMIT

Какие данные теперь в таблицах A и B?
15 май 15, 10:34    [17643538]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
hvlad
автоматическое резервирование таблицы по ходу выполнения DML

я как-то не уверен, что это можно назвать serializable, чтобы там борманы не писали на этот счет. Но возможно я слишком строг :-) Насколько я понимаю, без RESERVE работает оптимистический подход ("резервирование по ходу"), который может приводить к ошибкам сериализации в рантайме (хотя бы вследствие встречной блокировки A->B и B->A). А с RESERVE (упреждающие блокировки при старте транзакции) можно обеспечить бесконфликтную (читай: последовательную) работу конкурентов, но придется поработать ручками. Поправь меня, если ошибаюсь.
15 май 15, 10:57    [17643681]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
этта
Guest
PgSQLAnonymous,
у вас ус отклеился

у вас там таблички N непришейкобылехвост. [стюдент рука--лицо ]

и да -- в пж при сериалайзебл будет откат второй
+
ОШИБКА:  не удалось сериализовать доступ из-за зависимостей чтения/записи между транзакциями
DETAIL: Reason code: Canceled on identification as a pivot, during write.
HINT: Транзакция может завершиться успешно при следующей попытке.

а при repeatable read -- количество во второй будет соответствовать снепшоту при старте, а не нормальному, при read commited текущему состоянию.

резюме -- те, кто не умеют писать серверную логику [полк их надысь пополнился випросом] -- хотят сериалазебла, чтобы клиентская реализация чисто серверного функционала хоть как-то ползала.

кто умеет -- пишут инкрементальную, а не агрегатную логику на сервере, и требуют именно readcommited-а, а не маргинальных снапшотов и т.п.

все маргинальные уровни изоляции требуются только для развесистых агрегатов типа отчетов по плохо связанным наборам. -- чтобы синхронизировать снапшоты отдельных расчётов
15 май 15, 11:01    [17643714]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
PgSQLAnonymous
Вот тут я прямо заинтересовался. Доказательства-то этому есть?
Моего слова не достаточно ?
+
Сессия 1
firebird>isql localhost:c:\temp\a.fdb
Database:  localhost:c:\temp\a.fdb
SQL> CREATE TABLE N1(n INT);
SQL> CREATE TABLE N2(n INT);
SQL> CREATE TABLE A(n INT);
SQL> CREATE TABLE B(n INT);
SQL>
SQL> INSERT INTO N1 VALUES(1);
SQL> INSERT INTO N2 VALUES(1);
SQL> INSERT INTO A VALUES(0);
SQL> INSERT INTO B VALUES(0);
SQL> COMMIT;
SQL>

Сессия 2
isql localhost:c:\temp\a.fdb

Сессия 1
SQL> SET TRANSACTION SNAPSHOT TABLE STABILITY;
SQL> SELECT * FROM N1;

           N
============
           1

Сессия 2
SQL> SET TRANSACTION SNAPSHOT TABLE STABILITY;
Commit current transaction (y/n)?y
Committing.
SQL> SELECT * FROM N2;

           N
============
           1

Сессия 1
SQL> INSERT INTO B
CON> SELECT COUNT(*)
CON>   FROM A;
SQL> COMMIT;

Сессия 2
SQL> INSERT INTO A
CON> SELECT COUNT(*)
CON>   FROM B;
SQL> COMMIT;


Сессия 1
SQL> SELECT * FROM A;

           N
============
           0
           1

SQL> SELECT * FROM B;

           N
============
           0
           1
15 май 15, 11:14    [17643799]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
dimitr
Поправь меня, если ошибаюсь.
Не ошибаешься. А чем это противоречит сериализации ?
Или ты имеешь в виду, что в теории serializable тр-ции не могут получить ошибки из-за конкурентов ?
Ну, тогда - да, нет в FB такого уровня изоляции. А где есть ?
И - да, "вручную" (с явным резервированием) его таки можно достичь. А у других как ?
15 май 15, 11:19    [17643838]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Ну, тогда - да, нет в FB такого уровня изоляции. А где есть ?


MS SQL.
15 май 15, 11:26    [17643913]     Ответить | Цитировать Сообщить модератору
 Re: Чем плох блокировочник по сравнению с версионником?  [new]
PgSQLAnonymous
Member

Откуда:
Сообщений: 84
hvlad
PgSQLAnonymous
Вот тут я прямо заинтересовался. Доказательства-то этому есть?
Моего слова не достаточно ?

Конечно, недостаточно. Вы сами-то посмотрели на результат? ;)
Вот из этого:

SQL> SELECT * FROM A;
           N
============
           0
           1
SQL> SELECT * FROM B;
           N
============
           0
           1


Следует, что этот SNAPSHOT TABLE STABILITY ни разу не SERIALIZABLE.
Получиться-то должно было так:
SQL> SELECT * FROM A;
           N
============
           0
           1
SQL> SELECT * FROM B;
           N
============
           0
           2

или так:
SQL> SELECT * FROM A;
           N
============
           0
           2
SQL> SELECT * FROM B;
           N
============
           0
           1


Мораль: если производитель InterBase где-то утверждает, что "SNAPSHOT TABLE STABILITY" = SERIALIZABLE, это очередное переопределение терминов.
15 май 15, 11:44    [17644075]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить