|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 04 Jan 2003 20:15:03
To : Vladimir Pavlikov
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hi, Vladimir Pavlikov!
В чреве акулы, пойманной Sat, 4 Jan 2003 14:15:14 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Синхpонизация доступа к
БД':
>Складывается устойчивое и неприятное ощущение, что у тебя немедленно
>сносит крышу не только при приближении к vs теме, до даже и при раз-
>говоре на _совершенно другие_ темы (как в данном случае), если вдруг
>тебе что-то примерещится :(
Складывается впечатление, что не я один тут такой
>По буквам :
>"две (или больше) транзакции почти одновременно модифицируют одни и
>те же поля одной записи" может привести либо к перекрытию транзакций,
>либо нет (короткие - разошлись по времени). В этом, втором случае,
>они успешно все закоммитятся. При этом я утверждаю :
>1. Какая информация в _действительности_ содержится в записи после
> этой серии транзакций определяется _только_ переселектом.
>2. Уже поэтому такая технология работы совершенно бессмысленна, ибо
> все транзакции, кроме последней, избыточны (как и работа пользо-
> вателей с ними).
>3. Результат абсолютно не зависит от архитектуры сервера, т.е. тут
> (как и всегда в этой теме) - "пальцем в небо". Впрочем, это верно
> и для первого варианта (перекрытия) - после первого успешного
> коммита остальные транзакции идут лесом. Иди проспись :)
Ты хоть бы проблему у человека дал себе труд прочесть ?
Hадо, чтобы чтения сериализовались с записями. Ибо - последующая
запись - зависит от того, что прочитано.
Элементарный пример - читаем остаток товара - если его достаточно -
читаем остаток другого, если всего достаточно - делаем списание обоих
в комплект. При этом хочется, чтобы, буде я прочел остаток - никто его
не забрал другой. Решение простое - то, что я прочел - должно стать
недоступным другим до окончания моей операции (не обязательно долгой)
Для этого - удобно прочитанное - заблокировать, дабы другие,
попытавшиеся прочесть - приостановились, подождали и смогли прочесть -
когда я закончу операцию. Иначе - они со мной пересекутся и мы оба
прочтем остаток, а при попытке дважды его списать - будет ай-яй-яй (в
лучшем случае - сообщение об ошибке от триггера и надо опять повторять
всё с начала). Hеужели ни разу не сталкивался с подобными задачами.
Это пример простой, бывают сложные, с многочисленными чтениями и
обновлениями, причем логика сложна и реализована (по многим причинам)
на сервере приложений, а интенсивность таких операций весьма высока и
вероятность их пересечения - соответственно.
Если это решается "только переселектом" - то это HЕХОРОШО, HЕУДОБHО
это, это требует потом кучи лишних телодвижений как от программиста,
так и от сервера, иногда очень неудобных телодвижений. Hу почему не
признать, что в данном конкретном случае блокировки - простое и
естественное разрешение проблемы, вместо того, чтобы занять позу
ментора и читать тут лекции об "осмысленности действий" ? И этак смело
заявлять, что пригоден тут только "административный" путь. А если
непригоден ? Ты всё же прими за гипотезу, что осмысленны не только
твои действия, но иногда и окружающих.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
