FreemanZAVЭто значит, всего лишь хреновую реализацию. В fb, например, insert не особо мешает паралельной транзакции при повторе запроса возврашать неизменный набор.

Гм... Тут, кмк, стоит все-таки указывать, при каких TIL выполняется читающая транзакция.

hvladГм... Тут, кмк, стоит все-таки указывать, при каких TIL выполняется читающая транзакция.Не мешает - при любых. Если читатель - serializable, то insert ему тоже не помешает, ибо сам будет ждать окончания читателя.[/quot]

Гм... "при любых" и "Если читатель - serializable" подвигает меня к выводу, что в ib RR так же подвержен феномену фантомов, и уже получается, что не "при любых ...не особо мешает паралельной транзакции при повторе запроса возврашать неизменный набор"

FreemanZAV
Неожиданный и неверный вывод.

Т.е. RR в ib, как такового и нет?!И его заменяет SNAPSHOT, который, "якобы соответствует RR от ANSI SQL", за исключением того, что SNAPSHOT не обеспечивает видимость фантомов.

FreemanZAV
И ни чего не получается. В fb, наоборот возникают некотрые затруднения, если нужно заблокировать инсёрт для параллельной транзакции. Забавно, что люди делают выводы о том, о чём не имеют ни малейшего представления.

И эти "некоторые затруднения", насколько я понимаю, связана с отсутствием "честного" Serializable?!

Читаем:

Режимы транзакций сервера IBУровень изоляции SNAPSHOT.
Транзакция в момент старта получает "снимок" БД, который является неизменным до конца транзакции. Чтение данных, измененных конкурирующей транзакцией, разрешено, однако внесенные ей изменения не доступны. Попытка изменения данных, обновляемых другой транзакцией, приводит к конфликту (Deadlock, SQLCODE = -913). После завершения конкурирующих транзакций обновленные ими данные все равно изменять нельзя, поскольку полученный "снимок" уже не отражает текущего состояния БД (Deadlock. Update conflicts with concurrent update. SQLCODE = -913).

Оригинальная трактовка дедлока...

FreemanZAVТам есть лучше.
...
И просто зашибись, что не соответсвует
...
А от этого я вообще тащусь.

Лучше, зашибись и тащится можно когда есть и RR, и Serializable и Snapshot, как в MS SQL. ;)

FreemanZAVНу про затруднения я загнул немного,

Судя по всему, Вы не так далеки от истины.

FreemanZAVЯ не пойму, нахрена нужно блокировать всё и вся, если можно нормально, по тихому, многократно читать одни и те же данные и при этом не мешать другим делать insert, например. Причём довольно странно, что некоторые это воспринимают как минус.

Как "минус" воспринимается неполнота существующих уровней изоляции транзакций. А ситуации в жизни, когда возникает именно необходимость блокировать, возникают, и не так уж и редко.

FreemanZAVПо моему, всё логично.

Что-то я не вижу при одной читающей транзакции и одной с INSERT классической картины дедлока.

FreemanZAV
Особенно радует невозможность вставки записей в параллельных транзакциях.

Да уж, заблокировать MS SQL может лего, а вот что делать, когда нет такой необходимости?

Да потому что в fb читатель писателя не блокирует. Но, походу, MS SQL-щикам этого уже не понять никогда :(

Гы... Кто-то чуть выше безапелляционно упрекнул меня в неимении нималейшего представления о TIL в ib. Позволю себе сделать тоже самое в Ваш адрес и отправить к документации:
http://msdn.microsoft.com/en-us/library/ms189122.aspx :)

FreemanZAVЗа бутылку хорошего конъяка заблокирую в fb что угодно (хорошее объявление получилось, прямо для газеты "Из рук в руки" :-))

Я сделаю это даром. ;)

FreemanZAVТолько чудится мну, что работает это всё только в версионном режиме

Про то, что Вам чудится, можно по-подробнее?

FreemanZAVТак я идумал, господа, так я и думал (с)
If you set the READ_COMMITTED_SNAPSHOT database option to ON, the database engine uses row versioning

Это на тему топика.

Да пож-а:
Once snapshot isolation is enabled, updated row versions for each transaction are maintained in tempdb.

Гм... И к чему Вы привели эти цитаты?! В отличии от ib, MS SQL умеет работать и как версионник, и как блокировочник, и в смешанном режиме, когда при "включенной" версионности есть возможность наложения небходимых блокировок, т.е. возможность атомарного тютинга поведения.

Кмк, отличная возможность!