|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Dmitry Popov 2:5020/400 20 Feb 2001 19:36:31 To : All Subject : Re: Проблема с бо льшими таблицами -------------------------------------------------------------------------------- .ru> <96j820$alg$1@host.talk.ru> .ru> <Pine.LNX.4.31.0102161644240.14893-100000@popov.krista.ru> .ru> <96qt21$rrd$1@host.talk.ru> <3A913112.194751CA@demo.ru> .ru> <96rj0a$4ld$1@host.talk.ru> .ru> <Pine.LNX.4.31.0102201022520.3522-100000@popov.krista.ru> .ru> <96tm67$83d$2@host.talk.ru> From: Dmitry Popov <popov@krista.ru> On Tue, 20 Feb 2001, Vladimir Pavlikov wrote: > Hello! "Dmitry Popov" <popov@krista.ru> wrote: > > > Всё-таки хочу заметить, что "блокировка" и "выявление конфликтов" с моей > > точки зрения - вещи разные. Если конфликт выявлен и нарвавшаяся на него > > операция прервана, то это не блокировка. Блокировка - это когда операция > > на некоторое время приостанавливается до тех пор, пока не сложатся условия > > для её корректного выполнения. А как сложились, так выполняетя, а не > > обрубается. > > И с моей тоже. И что? > > > С этой точки зрения set transaction ... reserving ещё можно назвать > > блокировкой. А вот ситуацию с задержкой транзакции wait ... ну ладно, > > полублокировкой. > > Почему полу-? Потому что предыдущий абзац. Эта "блокировка" в большинстве случаев реально является окончательным прерыванием операции, а не её приостановкой. > > Потому что в некоторых случаях (если мешающая транзакция > > откатится по rollback), оно ещё может двинуться дальше. В подавляющем > > же большинстве вариантов его обрубят. > > Т.е. точно также, как и в блокировщике. Разница лишь в _событии_ при- > водящем к блокировке - львиная доля блокируемых _конфликтов_ для > блокировщика для версионника таковыми не являются. Hу может быть так - дальше уже вопрос терминологических вкусов. Тогда блокировочники блокируют по первому подозрению, а версионники - по доказанному факту. Кому-то нравится называть состояние между остановкой обработки и окончательной ликвидацией этой процесса этой обработки "блокировкой", а кому-то нет. -- Дмитрий Попов, mailto:popov@krista.ru --- ifmail v.2.15dev5 * Origin: Krista NPO (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/1058418bea8aa.html, оценка из 5, голосов 10
|