|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 04 Jan 2003 21:19:54
To : Tolik Tentser
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hello, Tolik Tentser!
You wrote to Vladimir Pavlikov on Sat, 4 Jan 2003 16:15:03 +0000 (UTC):
>> "две (или больше) транзакции почти одновременно модифицируют одни и
>> те же поля одной записи" может привести либо к перекрытию транзакций,
>> либо нет (короткие - разошлись по времени). В этом, втором случае,
>> они успешно все закоммитятся. При этом я утверждаю :
>> 1. Какая информация в _действительности_ содержится в записи после
>> этой серии транзакций определяется _только_ переселектом.
>> 2. Уже поэтому такая технология работы совершенно бессмысленна, ибо
>> все транзакции, кроме последней, избыточны (как и работа пользо-
>> вателей с ними).
>> 3. Результат абсолютно не зависит от архитектуры сервера, т.е. тут
>> (как и всегда в этой теме) - "пальцем в небо". Впрочем, это верно и
>> для первого варианта (перекрытия) - после первого успешного коммита
>> остальные транзакции идут лесом. Иди проспись :)
TT> Ты хоть бы проблему у человека дал себе труд прочесть ?
Т.е. против вышенаписанного возражений нет? А ведь писал я _тебе_ -
при чем тут "проблема _другого_ человека"?
TT> Hадо, чтобы чтения сериализовались с записями. Ибо - последующая
TT> запись - зависит от того, что прочитано.
TT> Элементарный пример - читаем остаток товара - если его достаточно -
TT> читаем остаток другого, если всего достаточно - делаем списание
TT> обоих в комплект. При этом хочется, чтобы, буде я прочел остаток -
TT> никто его не забрал другой. Решение простое - то, что я прочел -
TT> должно стать недоступным другим до окончания моей операции (не
TT> обязательно долгой)
Это _твой_ пример. А ссылаешься ты на проблему "человека". Каковой
писал о _другом_ :
DVL> Предположим, есть некое дерево папок. То есть каждая папка имеет
DVL> FK, ссылающийся на родительскую папку.
DVL> Есть некий справочник информации, связанной с этими папками
DVL> (Таблица, где каждая запись имеет FK папки).
DVL> Первый пользователь запускает операцию удаления папки, сервер
DVL> приложений стартует транзакцию и начинает рекурсивно удалять все
DVL> вложенные папки и связанную с ними информацию из справочников.
DVL> Второй пользователь пытается создать новую папку где-то в глубине
DVL> иерархии.
Именно это я и назвал "административной" проблемой, проиллюстрировав
ее на более простом примере. Тут, как видишь, предчтением и не
пахнет - одни удаления/вставки. И минимум одна из операций бессмысленна
изначально, вне БД - по смыслу.
TT> Для этого - удобно прочитанное - заблокировать, дабы другие,
TT> попытавшиеся прочесть - приостановились, подождали и смогли прочесть
TT> -
TT> когда я закончу операцию. Иначе - они со мной пересекутся и мы оба
TT> прочтем остаток, а при попытке дважды его списать - будет ай-яй-яй
TT> (в лучшем случае - сообщение об ошибке от триггера и надо опять
TT> повторять всё с начала). Hеужели ни разу не сталкивался с подобными
TT> задачами.
Hу почему же, сталкивался. И решал ее именно так в некотором ряде
случаев. В других - иначе, задачезависимо. Вот только к обсуждавшемуся
вопросу это отношения не имеет. То ли ты сам не дал себе труда сделать
то, чего "с меня требовал", то ли не понял. Мой текст стопроцентно
"понял" неверно. И попытка подменить один вопрос другим тебе ни к лицу.
TT> Это пример простой, бывают сложные, с многочисленными чтениями и
TT> обновлениями, причем логика сложна и реализована (по многим
TT> причинам)
TT> на сервере приложений, а интенсивность таких операций весьма высока
TT> и вероятность их пересечения - соответственно.
TT> Если это решается "только переселектом" - то это HЕХОРОШО, HЕУДОБHО
Да не "это", не это...
TT> естественное разрешение проблемы, вместо того, чтобы занять позу
TT> ментора и читать тут лекции об "осмысленности действий" ? И этак
TT> смело заявлять, что пригоден тут только "административный" путь. А
TT> если непригоден ? Ты всё же прими за гипотезу, что осмысленны не
TT> только твои действия, но иногда и окружающих.
Мои "менторские" заявления лучше опровергать не литературными упраж-
нениями, а чем-то более осмысленным. Да, я утверждаю, что в моем
примере и в изначальном вопросе проблема имеет именно административный
характер. А для гипотез нужны основания. В твоей [неуклюжей] попытке
выкрутиться заменой темы я оснований для формирования гипотез не вижу.
Да и тебе многие из возможных не понравятся, а я к тебе (в целом)
отношусь-таки неплохо :)
---------------------------------------------
Владимир Павликов.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
