|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 08 Jun 2001 13:26:21
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Hello! "Sergey Practh" <sltoopls@kot.poltava.ua> wrote:
> > Это позволит избежать дедлока, но увеличит количество блокировок, т.е.
> > затормозит пользователей. Лучше правильно выбрать уровень изоляции и
> > сместить все модификации в конец транзакции, пропустив вперед все
> > [объемные] запросы. Возни несколько больше, но и результат другой.
> > А ТАК нужно делать лишь в случаях, когда вышенаписанное невозможно.
> > А вот такого быть (почти) не должно :)
> Hе скогласен! Если мне до начала транзакции известен список записей,
> которые будут модифицироватся (типичная ситуация: обновление значения
> остатков на счетах в триггере), то откуда может быть эскалация количества
> блокировок в самой транзакции? Вместо того, что бы их блокировать по мере
> выполнения транзакции, я просто беру и блокирую их сразу все.
Чем дольше период блокирования, чем выше вероятность остановки параллельных
транзакций и больше время "зависа".
> Время выполнения одиночного SELECT на порядок меньше, чем время UPDATE
> на таким же наором записей и на нгесколько порядков меньше времени
> выполнения всей транзакции. Это означает, что я могу получить "замок" только
> в момент выполнения самого SELECT, а значит шанс возникновения "замка"
> уменьшается в сотни-тысячи раз.
Речь не о замке, а о времени блокирования. С порядками ты погорячился,
и почему речь только о update _на том же самом наборе_? Очень частный
случай. Про "на нгесколько порядков меньше времени выполнения всей
транзакции" я уж умолчу. Hо все же рассмотри транзакцию, состоящую
из selecta по громадной таблице и одного insert'а с количеством
записей, удовлетворяющих условию selecta :))
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
