Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Ой, а у Вас ACID потёк. ;)  [new]
MSSQLBug
Guest
Добрый день.

Сразу к демонстрации. Подготовка:
CREATE TABLE dbo.TESTTABLE (A INT PRIMARY KEY);
INSERT INTO TESTTABLE (A) VALUES(1);
INSERT INTO TESTTABLE (A) VALUES(2);
INSERT INTO TESTTABLE (A) VALUES(3);
INSERT INTO TESTTABLE (A) VALUES(4);
INSERT INTO TESTTABLE (A) VALUES(5);


Далее, две сессии:

-- Первая:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRANSACTION
-- Вторая:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRANSACTION
-- Первая:
INSERT INTO dbo.TESTTABLE VALUES(6);
-- Вторая (блокируется):
INSERT INTO dbo.TESTTABLE VALUES(6);
-- Первая:
COMMIT
-- Вторая, ошибка: Violation of PRIMARY KEY constraint '...'. Cannot insert duplicate key in object 'dbo.TESTTABLE'.
-- Во второй сессии:
SELECT * FROM dbo.TESTTABLE WHERE a = 6
-- результат: 0 rows


Я понимаю, почему это происходит, но выглядит это как столкновение с невидимой стеной. ;)
Т.е. MS SQL мне говорит, что я пытаюсь вставить запись, которая уже есть, смотрю --- а её нет!

Почему в данном случае выдаётся не "Snapshot isolation transaction aborted due to update conflict."?
29 дек 14, 16:54    [17068567]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8805
MSSQLBug,

во второй сессии происходит откат вставки, чего же непонятного? Поэтому данных ноль.
29 дек 14, 18:11    [17068994]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8805
В смысле - не откат, а отмена. Но данные зафиксированы на момент начала транзакции уровнем изоляции (0 записей).
29 дек 14, 18:13    [17069005]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
MSSQLBug
Guest
Владислав Колосов
во второй сессии происходит откат вставки, чего же непонятного? Поэтому данных ноль.
В смысле - не откат, а отмена. Но данные зафиксированы на момент начала транзакции уровнем изоляции (0 записей).

Как я уже говорил:
MSSQLBug
Я понимаю, почему это происходит,

А по заданному вопросу Вы что думаете?
29 дек 14, 21:50    [17069627]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4256
MSSQLBug
Почему в данном случае выдаётся не "Snapshot isolation transaction aborted due to update conflict."?


а где вы там update написали? и разве слово "блокировка" уместно в контексте уровня?

там паралельные миры, но в итоге таки да - правильный результат
30 дек 14, 00:15    [17070146]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
aleks2
Guest
MSSQLBug
Добрый день.

Сразу к демонстрации. Подготовка:
CREATE TABLE dbo.TESTTABLE (A INT PRIMARY KEY);
INSERT INTO TESTTABLE (A) VALUES(1);
INSERT INTO TESTTABLE (A) VALUES(2);
INSERT INTO TESTTABLE (A) VALUES(3);
INSERT INTO TESTTABLE (A) VALUES(4);
INSERT INTO TESTTABLE (A) VALUES(5);


Далее, две сессии:

-- Первая:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRANSACTION
-- Вторая:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRANSACTION
-- Первая:
INSERT INTO dbo.TESTTABLE VALUES(6);
-- Вторая (блокируется):
INSERT INTO dbo.TESTTABLE VALUES(6);
-- Первая:
COMMIT
-- Вторая, ошибка: Violation of PRIMARY KEY constraint '...'. Cannot insert duplicate key in object 'dbo.TESTTABLE'.
-- Во второй сессии:
SELECT * FROM dbo.TESTTABLE WHERE a = 6
-- результат: 0 rows


Я понимаю, почему это происходит, но выглядит это как столкновение с невидимой стеной. ;)
Т.е. MS SQL мне говорит, что я пытаюсь вставить запись, которая уже есть, смотрю --- а её нет!

Почему в данном случае выдаётся не "Snapshot isolation transaction aborted due to update conflict."?


Забавный, конечно, пример для понимания сути снапшот-изоляции. Но вполне ожидаемо.

-- вот так интереснее будет
-- Вторая (блокируется):
INSERT INTO dbo.TESTTABLE select 6 where not exists( select * from dbo.TESTTABLE where A = 6 ) ;
-- Первая:
30 дек 14, 07:40    [17070619]     Ответить | Цитировать Сообщить модератору
 Re: Ой, а у Вас ACID потёк. ;)  [new]
MSSQLBug
Guest
Lepsik
а где вы там update написали?


UPDATE здесь писать и не обязательно:

-- После открытия транзакций, см. в первом сообщении темы
-- Первая:
UPDATE dbo.TESTTABLE SET A=10 WHERE A=5;
-- Вторая (блокируется):
INSERT INTO dbo.TESTTABLE VALUES(5);
-- Первая:
COMMIT
-- Вторая, ошибка:

Snapshot isolation transaction aborted due to update conflict. 
You cannot use snapshot isolation to access table 'dbo.TESTTABLE'
directly or indirectly in database 'test' to update, delete, or insert
the row that has been modified or deleted by another transaction.
Retry the transaction or change the isolation level for the update/delete statement.

Lepsik
и разве слово "блокировка" уместно в контексте уровня?

А почему нет? Вторая транзакция именно блокируется.

Lepsik
там паралельные миры, но в итоге таки да - правильный результат


То есть сервер из закомиченной транзакции вернул мне противоречащие друг другу результаты:
  • Вставка записи не удалась из-за того, что она уже есть.
  • Такой записи нет.
    И это, по-Вашему, правильный результат?! А по-моему, сервер мне попросту врёт. ;)
    IMHO, это нарушение ISOLATION. Хоть SNAPSHOT и не SERIALIZABLE, мне интересно, почему было выбрана такая реакция на ошибку (duplicate key), а не update conflict.
  • 30 дек 14, 09:19    [17070869]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 8805
    MSSQLBug, насколько я понимаю из идеологии, изоляция снапшотом должна предотвращать конфликты чтения, с чем, судя по примеру, она отлично справляется.
    30 дек 14, 11:58    [17071818]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    MSSQLBug
    Guest
    Владислав Колосов
    MSSQLBug, насколько я понимаю из идеологии, изоляция снапшотом должна предотвращать конфликты чтения, с чем, судя по примеру, она отлично справляется.


    Она бы с этим справлялась ещё лучше, возвращая другую ошибку в этом случае, IMHO.
    30 дек 14, 12:11    [17071918]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    Павел-П
    Member

    Откуда:
    Сообщений: 234
    MSSQLBug,

    Я так понимаю, у вас больше претензии не к ACID, а к обработке ошибки.
    30 дек 14, 12:52    [17072273]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    msLex
    Member

    Откуда:
    Сообщений: 9271
    Павел-П
    а к обработке ошибки.

    видимо к тексту
    30 дек 14, 13:01    [17072341]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    daw
    Member

    Откуда: Муром -> Москва
    Сообщений: 7381
    msLex
    видимо к тексту


    у меня получается, что update conflict еще и транзакцию откатывает. violation of primary key такого без xact_abort on не делает.
    30 дек 14, 13:27    [17072527]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    MSSQLBug
    Guest
    Павел-П
    MSSQLBug,
    Я так понимаю, у вас больше претензии не к ACID, а к обработке ошибки.

    Я считаю, что для сохранения ACID должен возвращаться update conflict. А так получается, что изоляция "течёт", т.е. получить эту ошибку и не найти соответствующей записи возможно только из-за параллельно выполняющихся транзакций.
    30 дек 14, 13:39    [17072603]     Ответить | Цитировать Сообщить модератору
     Re: Ой, а у Вас ACID потёк. ;)  [new]
    MSSQLBug
    Guest
    msLex
    видимо к тексту

    Ну, не только, ещё и к коду ошибки. ;) И поведение другое, при update conflict обычно выполняется откат транзакции.
    А если Вас тексты ошибок не интересуют --- почему бы серверу не возвращать произвольные? ;)
    30 дек 14, 13:42    [17072625]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить