|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Practh 2:5020/400 07 Jun 2001 22:22:21
To : All
Subject : Hа: Informix ?
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:9fnnes$vu1$1@host.talk.ru...
> > >просто перед началом любой транзакции, котороая может приводить к
> > >такой ситуации, заблокировать все необходимые ресурсы одним запросом, а
в
> > >большинстве случаев это возможно. Т.е перед тем как начать перекрестное
>
> > Все правильно, так и HАДО делать.
>
> Это позволит избежать дедлока, но увеличит количество блокировок, т.е.
> затормозит пользователей. Лучше правильно выбрать уровень изоляции и
> сместить все модификации в конец транзакции, пропустив вперед все
> [объемные] запросы. Возни несколько больше, но и результат другой.
> А ТАК нужно делать лишь в случаях, когда вышенаписанное невозможно.
> А вот такого быть (почти) не должно :)
Hе скогласен! Если мне до начала транзакции известен список записей,
которые будут модифицироватся (типичная ситуация: обновление значения
остатков на счетах в триггере), то откуда может быть эскалация количества
блокировок в самой транзакции? Вместо того, что бы их блокировать по мере
выполнения транзакции, я просто беру и блокирую их сразу все.
Время выполнения одиночного SELECT на порядок меньше, чем время UPDATE
на таким же наором записей и на нгесколько порядков меньше времени
выполнения всей транзакции. Это означает, что я могу получить "замок" только
в момент выполнения самого SELECT, а значит шанс возникновения "замка"
уменьшается в сотни-тысячи раз.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
