|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
СУБД можно условно разделаить на два вида блокировочники и версионники. Блокировочники для изоляции транзакций накладывают блокировки, а версионники хранят версии актуальных данных для транзакции. Но зачастую в разговоре о версионниках говорят про блокировки, не совсем понимаю откуда если это версионник? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 03:30 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Зависит от сервера. На Firebird под блокировками обычно подразумевают конфликты обновлений. Если транзакция A изменила запись но транзакция не завершена то в транзакции B эту же запись изменить уже нельзя. Ну и еще масса тонкостей про блокирование от изменений читай про уровни изоляции транзакций, причем не абстрактно а именно про Firebird ибо у каждого сервера в этом месте свои тонкости. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 06:46 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Даже версионник использует блокировки для обеспечения одновременного доступа к данным. Они используются чтобы в каждый момент времени только одна транзакция могла изменять конкретные данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 09:28 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
AndronДаже версионник использует блокировки для обеспечения одновременного доступа к данным. Точнее будет сказать - для синхронизации доступа к общим/глобальным объектам. Это необязательно данные. Аффтар, почитай хоть что-нибудь про программирование многопоточных приложений. Того же Рихтера, например. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 11:45 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЭто необязательно данные. а что? Оо ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 12:09 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Зайцев Фёдора что? Оо Метаданные, файловые ресурсы, коммуникации... Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 12:13 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
On 14.04.2011 4:30, версионник wrote: > СУБД можно условно разделаить на два вида блокировочники и версионники. > Блокировочники для изоляции транзакций накладывают блокировки, а версионники > хранят версии актуальных данных для транзакции. > Но зачастую в разговоре о версионниках говорят про блокировки, не совсем понимаю > откуда если это версионник? Две модификации одной и той же строки в разных транзакциях будут друг друга блокировать ДАЖЕ В ВЕРСИОННИКЕ. Если они это не будут делать, будет проблема (аномания), именуемая write skew, можешь про неё прочитать в той же википедии. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 12:20 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Простой пример в версионнике с двумя транзакциями TX1 и TX2 которые обновляют запись N1 TTX1TX21 обновляет запись N1 -2-пытается обновить N1 - ждет снятия блокировки3commit-4-обновила запись N1 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 12:55 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
AndronПростой пример в версионнике Это не в версионнике, это в Оракуле. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 12:57 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, в postgres так же. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 15:07 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
да и у майкрософт на версионных уровнях так же, ФБ как всегда особенный :) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 15:29 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Да, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим... Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 15:36 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДа, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим... ну... в этом как бы суть любого апдэйта ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 15:38 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Зайцев ФёдорDimitry SibiryakovДа, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим... ну... в этом как бы суть любого апдэйтаМожет таки огласим сначала уровень изоляции tx2 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 15:48 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
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.04.2011, 15:58 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
AndronПростой пример в версионнике с двумя транзакциями TX1 и TX2 которые обновляют запись N1 TTX1TX21 обновляет запись N1 -2-пытается обновить N1 - ждет снятия блокировки3commit-4-обновила запись N1 А если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3? TTX1TX2TX30 - - старт транзакции1 старт транзакции - -2читает V1 - читает V13 - (читает что-то ещё) - меняет V14 - - commit5 - старт транзакции -6 - меняет V1 -7 - commit -8 меняет V1 - -9 commit - - Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1? Dimitry SibiryakovДа, да, вот так молча грохнуть чужие изменения... Суровый этот мейнстрим... А на Firebird будет deadlock? И на всех уровнях изоляции? Dimitry SibiryakovЗайцев Фёдора что? Оо Метаданные, файловые ресурсы, коммуникации... Сиквенсы например. А метаданные, в частности для структур таблиц ни в одной СУБД не используются версии? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 16:12 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
версионник... А если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3? TTX1TX2TX30 - - старт транзакции1 старт транзакции - -2читает V1 - читает V13 - (читает что-то ещё) - меняет V14 - - commit5 - старт транзакции -6 - меняет V1 -7 - commit -8 меняет V1 - -9 commit - - Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1? ... Ключевой вопрос здесь "как читает TX1 или TX3 в момент 2" (для простоты будем считать что TX2 прочитала раньше чем TX3): если будет произведено чтение for update то ни одна другая транзакция после этого момента и до коммита TX1 изменить запись V1 не сможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 16:32 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
On 14.04.2011 13:57, Dimitry Sibiryakov wrote: > Это не в версионнике, это в Оракуле. Оракул версионник. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 16:40 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
версионникА если допустим между Т1 и Т2 влезла ещё одна транзакция Т3, которая изменила данные, то Т1 их просто не увидит и произведет свои изменения без учета Т3? TTX1TX2TX30 - - старт транзакции1 старт транзакции - -2читает V1 - читает V13 - (читает что-то ещё) - меняет V14 - - commit5 - старт транзакции -6 - меняет V1 -7 - commit -8 меняет V1 - -9 commit - - Т.е. ни изменения Т3, ни изменения Т2 учтены не буду относительно V1? вообще-то если не отдельно читать/ отдельно менять, а "менять, читая", одним стейтментом ~ Код: plaintext
А если провернуть всё в одном стейтменте не удается - то читать надо FOR UPDATE , как подсказывают. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 18:15 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Зайцев Фёдорну... в этом как бы суть любого апдэйта И ведь что самое забавное: если я сейчас начну рассуждать о репликации и скажу, что при изменении одних и тех же данных на двух серверах, одно из изменений будет молча затёрто другим, то эти же самые люди будут кричать, что это абсолютно неправильно. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 18:44 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
1chainikвообще-то если не отдельно читать/ отдельно менять, а "менять, читая", одним стейтментом ~ Код: plaintext
А если провернуть всё в одном стейтменте не удается - то читать надо FOR UPDATE , как подсказывают. Т.е. правильно понимаю, что даже в версионнике в двух транзакциях используя FOR UPDATE можно получить deadlock при read commited, а при Serializable и без FOR UPDATE? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 20:29 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
deadlock и update conflict это две большие разницы вообще-то... Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 20:41 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovdeadlock и update conflict это две большие разницы вообще-то... А в чем именно разница, насколько я понимаю в обоих случаях одна из транзакций наименее затратная уйдет с rollback'ом. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 21:08 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
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.04.2011, 21:12 |
|
Откуда блокировки на версионниках?
|
|||
---|---|---|---|
#18+
версионникнасколько я понимаю в обоих случаях одна из транзакций наименее затратная уйдет с rollback'ом. Нинасколько ты не понимаешь. Update conflict это штатная ошибка параллельного апдейта. Deadlock это нештатная ситуация взаимного ожидания. При первом никакой взаимности нет. Второй всегда обломится (если первый не откатится добровольно). Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2011, 21:31 |
|
|
start [/forum/topic.php?fid=35&msg=37215702&tid=1552698]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
1ms |
others: | 243ms |
total: | 401ms |
0 / 0 |