Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Откуда блокировки на версионниках?  [new]
версионник
Guest
СУБД можно условно разделаить на два вида блокировочники и версионники.
Блокировочники для изоляции транзакций накладывают блокировки, а версионники хранят версии актуальных данных для транзакции.
Но зачастую в разговоре о версионниках говорят про блокировки, не совсем понимаю откуда если это версионник?
14 апр 11, 03:30    [10516137]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
fraks
Member

Откуда: Новосибирск
Сообщений: 1831
Зависит от сервера.
На Firebird под блокировками обычно подразумевают конфликты обновлений.
Если транзакция A изменила запись но транзакция не завершена то в транзакции B эту же запись изменить уже нельзя.
Ну и еще масса тонкостей про блокирование от изменений читай про уровни изоляции транзакций, причем не абстрактно а именно про Firebird ибо у каждого сервера в этом месте свои тонкости.
14 апр 11, 06:46    [10516197]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
Даже версионник использует блокировки для обеспечения одновременного доступа к данным. Они используются чтобы в каждый момент времени только одна транзакция могла изменять конкретные данные.
14 апр 11, 09:28    [10516488]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

Andron
Даже версионник использует блокировки для обеспечения одновременного доступа к данным.

Точнее будет сказать - для синхронизации доступа к общим/глобальным объектам. Это
необязательно данные.

Аффтар, почитай хоть что-нибудь про программирование многопоточных приложений. Того же
Рихтера, например.

Posted via ActualForum NNTP Server 1.4

14 апр 11, 11:45    [10517328]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
Dimitry Sibiryakov
Это необязательно данные.
а что? Оо
14 апр 11, 12:09    [10517532]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

Зайцев Фёдор
а что? Оо

Метаданные, файловые ресурсы, коммуникации...

Posted via ActualForum NNTP Server 1.4

14 апр 11, 12:13    [10517565]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 14.04.2011 4:30, версионник wrote:
> СУБД можно условно разделаить на два вида блокировочники и версионники.
> Блокировочники для изоляции транзакций накладывают блокировки, а версионники
> хранят версии актуальных данных для транзакции.
> Но зачастую в разговоре о версионниках говорят про блокировки, не совсем понимаю
> откуда если это версионник?

Две модификации одной и той же строки в разных транзакциях будут друг друга
блокировать ДАЖЕ В ВЕРСИОННИКЕ. Если они это не будут делать, будет проблема
(аномания), именуемая write skew, можешь про неё прочитать в той же википедии.

Posted via ActualForum NNTP Server 1.4

14 апр 11, 12:20    [10517628]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
Простой пример в версионнике с двумя транзакциями TX1 и TX2 которые обновляют запись N1

TTX1TX2
1 обновляет запись N1 -
2-пытается обновить N1 - ждет снятия блокировки
3commit-
4-обновила запись N1
14 апр 11, 12:55    [10517887]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

Andron
Простой пример в версионнике

Это не в версионнике, это в Оракуле.

Posted via ActualForum NNTP Server 1.4

14 апр 11, 12:57    [10517898]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Ёш
Member

Откуда:
Сообщений: 2892
Dimitry Sibiryakov, в postgres так же.
14 апр 11, 15:07    [10518883]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Yo.!
Guest
да и у майкрософт на версионных уровнях так же, ФБ как всегда особенный :)
14 апр 11, 15:29    [10519064]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим...

Posted via ActualForum NNTP Server 1.4

14 апр 11, 15:36    [10519117]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
Dimitry Sibiryakov
Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим...

ну... в этом как бы суть любого апдэйта
14 апр 11, 15:38    [10519129]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Зайцев Фёдор
Dimitry Sibiryakov
Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим...

ну... в этом как бы суть любого апдэйта
Может таки огласим сначала уровень изоляции tx2 ?
14 апр 11, 15:48    [10519184]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим...



MS SQL

In a read-committed transaction using row versioning, the selection of rows to update is done using a blocking scan where an update (U) lock is taken on the data row as data values are read. This is the same as a read-committed transaction that does not use row versioning. If the data row does not meet the update criteria, the update lock is released on that row and the next row is locked and scanned.

Transactions running under snapshot isolation take an optimistic approach to data modification by acquiring locks on data before performing the modification only to enforce constraints. Otherwise, locks are not acquired on data until the data is to be modified. When a data row meets the update criteria, the snapshot transaction verifies that the data row has not been modified by a concurrent transaction that committed after the snapshot transaction began. If the data row has been modified outside of the snapshot transaction, an update conflict occurs and the snapshot transaction is terminated. The update conflict is handled by the Database Engine and there is no way to disable the update conflict detection.
14 апр 11, 15:58    [10519243]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
версионник
Guest
Andron
Простой пример в версионнике с двумя транзакциями TX1 и TX2 которые обновляют запись N1

TTX1TX2
1 обновляет запись N1 -
2-пытается обновить N1 - ждет снятия блокировки
3commit-
4-обновила запись N1


А если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3?
TTX1TX2TX3
0 - - старт транзакции
1 старт транзакции - -
2читает V1 - читает V1
3 - (читает что-то ещё) - меняет V1
4 - - commit
5 - старт транзакции -
6 - меняет V1 -
7 - commit -
8 меняет V1 - -
9 commit - -

Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1?

Dimitry Sibiryakov
Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим...

А на Firebird будет deadlock?
И на всех уровнях изоляции?

Dimitry Sibiryakov
Зайцев Фёдор
а что? Оо

Метаданные, файловые ресурсы, коммуникации...

Сиквенсы например.
А метаданные, в частности для структур таблиц ни в одной СУБД не используются версии?
14 апр 11, 16:12    [10519330]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Andron
Member

Откуда: Cherepovets
Сообщений: 1816
версионник
...
А если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3?
TTX1TX2TX3
0 - - старт транзакции
1 старт транзакции - -
2читает V1 - читает V1
3 - (читает что-то ещё) - меняет V1
4 - - commit
5 - старт транзакции -
6 - меняет V1 -
7 - commit -
8 меняет V1 - -
9 commit - -

Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1?

...


Ключевой вопрос здесь "как читает TX1 или TX3 в момент 2" (для простоты будем считать что TX2 прочитала раньше чем TX3): если будет произведено чтение for update то ни одна другая транзакция после этого момента и до коммита TX1 изменить запись V1 не сможет.
14 апр 11, 16:32    [10519477]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 14.04.2011 13:57, Dimitry Sibiryakov wrote:
> Это не в версионнике, это в Оракуле.

Оракул версионник.

Posted via ActualForum NNTP Server 1.4

14 апр 11, 16:40    [10519555]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
1chainik
Member [заблокирован]

Откуда:
Сообщений: 295
версионник
А если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3?
TTX1TX2TX3
0 - - старт транзакции
1 старт транзакции - -
2читает V1 - читает V1
3 - (читает что-то ещё) - меняет V1
4 - - commit
5 - старт транзакции -
6 - меняет V1 -
7 - commit -
8 меняет V1 - -
9 commit - -

Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1?

вообще-то если не отдельно читать/ отдельно менять, а "менять, читая", одним стейтментом ~
SET t.x=t.x+delta
то в момент 8 при read commited T1 должна прочитать все закоммиченные на этот момент изменения в t.x. и их и наварить. мне кааца.

А если провернуть всё в одном стейтменте не удается - то читать надо FOR UPDATE , как подсказывают.
14 апр 11, 18:15    [10520272]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

Зайцев Фёдор
ну... в этом как бы суть любого апдэйта

И ведь что самое забавное: если я сейчас начну рассуждать о репликации и скажу, что при
изменении одних и тех же данных на двух серверах, одно из изменений будет молча затёрто
другим, то эти же самые люди будут кричать, что это абсолютно неправильно.

Posted via ActualForum NNTP Server 1.4

14 апр 11, 18:44    [10520395]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
версионник
Guest
1chainik
вообще-то если не отдельно читать/ отдельно менять, а "менять, читая", одним стейтментом ~
SET t.x=t.x+delta
то в момент 8 при read commited T1 должна прочитать все закоммиченные на этот момент изменения в t.x. и их и наварить. мне кааца.

А если провернуть всё в одном стейтменте не удается - то читать надо FOR UPDATE , как подсказывают.

Т.е. правильно понимаю, что даже в версионнике в двух транзакциях используя FOR UPDATE можно получить deadlock при read commited, а при Serializable и без FOR UPDATE?
14 апр 11, 20:29    [10520659]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

deadlock и update conflict это две большие разницы вообще-то...

Posted via ActualForum NNTP Server 1.4

14 апр 11, 20:41    [10520675]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
версионник
Guest
Dimitry Sibiryakov
deadlock и update conflict это две большие разницы вообще-то...

А в чем именно разница, насколько я понимаю в обоих случаях одна из транзакций наименее затратная уйдет с rollback'ом.
14 апр 11, 21:08    [10520734]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

On 14.04.2011 21:29, версионник wrote:

> Т.е. правильно понимаю, что даже в версионнике в двух транзакциях используя FOR
> UPDATE можно получить deadlock при read commited,
Да

а при Serializable и без FOR
> UPDATE?

DEADLOCK вообще можно получить всегда. В любой СУБД, на любом уровне изоляции.
(изменение данных работает на самом минимальном уровне изоляции, меньше 0,
так что уровни тут вообще ни при чём).

Posted via ActualForum NNTP Server 1.4

14 апр 11, 21:12    [10520739]     Ответить | Цитировать Сообщить модератору
 Re: Откуда блокировки на версионниках?  [new]
Dimitry Sibiryakov
Member

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

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

Нинасколько ты не понимаешь. Update conflict это штатная ошибка параллельного апдейта.
Deadlock это нештатная ситуация взаимного ожидания. При первом никакой взаимности нет.
Второй всегда обломится (если первый не откатится добровольно).

Posted via ActualForum NNTP Server 1.4

14 апр 11, 21:31    [10520776]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить