|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Anatoly Moskovsky 2:5020/400 11 Apr 2001 21:32:22
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Привет!
"Ilya Zvyagin" <ziv@fct.ru> wrote in message
news:987000847.471833@gatekeeper.fct.ru...
>
> >> Таких нет. Hо это можно элементарно сделать последовательно.
> >Что значит последовательно? Коммит после каждой вставки строки ?
>
> Вот именно.
>
Ты неправ.
Это можно сделать, но не всегда, так как выполнение коммит означает, что
данные в базе находятся в согласованном с бизнес-логикой состоянии. А
бизнес-логика может требовать, например, чтобы не было документов без
позиций, и если выполнять коммит после каждой строки, то это правило нельзя
реализовать.
>
> >Что ты имел ввиду: что разницы нет, и блокировки одинаково непричем?
>
> Цитирую тебя :
> Сессия может открыть параллельную транзакцию, в ней увеличить счетчик и
> выполнить коммит, а основная транзакция при этом не завершена.
> В этом случае вероятность блокировки почти = 0.
>
> В этом случае парралельная транзакция будет блокировать основную, впрочем,
> как и все другие. Вероятность блокировок при этом никак видимо не
> измениться,
> ну разве что только продолжительность транзакций уменьшиться, и за счет
> этого.
>
Да действительно блокировки строк будут в любом случае. Hо сами по себе
блокировки не страшны, гораздо важнее время, в течении которого, несколько
конкурентных сессий ожидают снятия блокировки.
Если счетчик увеличивать в той же транзакции, где происходит модификация
данных, то другим сессиям придется ждать окончания транзакции, первой
увеличившей счетчик. А учитывая что транзакция в общем случае состоит из
нескольких операторов (а не из одного, как у тебя), и в данном случае это
операторы вставки, то транзакция может занять значительное время.
Если же счетчик увеличивать в автономной транзакции и сразу закрывать ее, то
время ожидания у других сессий будет равно времени выполнения операторов
update, commit. А эти операторы выполнятся несравнимо быстрей чем даже один
insert, не говоря уже о серии операторов.
Бай
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
