|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 10 Jan 2003 17:39:59
To : Tolik Tentser
Subject : Re: Синхpонизация доступа к БД
--------------------------------------------------------------------------------
Hello, Tolik Tentser!
You wrote to Vladimir Pavlikov on Thu, 9 Jan 2003 16:32:32 +0000 (UTC):
TT>>> Вот именно переселект - и нежелателен и неудобен
>> Опять двадцать пять :( Я не спрашиваю, удобен или нет. Я _утверждаю_,
>> что в _описанной_ ситуации он неизбежен. Где _возражения_?
TT> Он более чем "избежен". если у удаляющей транзакции есть возможность
TT> исключить доступ (в том числе и чтение) к удаляемым данным. Hа время
TT> изменения. И никакого переселекта не понадобится, другие транзакции
TT> получат новое состояние папок.
Заклинило? :( Повторюсь :
> По буквам :
> "две (или больше) транзакции почти одновременно модифицируют одни и
> те же поля одной записи" может привести либо к перекрытию транзакций,
> либо нет (короткие - разошлись по времени). В этом, втором случае,
> они успешно все закоммитятся. При этом я утверждаю :
> 1. Какая информация в _действительности_ содержится в записи после
> этой серии транзакций определяется _только_ переселектом.
> 2. Уже поэтому такая технология работы совершенно бессмысленна, ибо
> все транзакции, кроме последней, избыточны (как и работа пользо-
> вателей с ними).
Вот и продемонстрируй нам "избежность" для случая, когда две транзакции
успели пройти _друг за другом_.
>> версионный сервер
>> отработает точно так же, заблокировав прочитанные сообщения. И точно
>> так же, как и в блокираторе, это будет техническая "затычка" _нетех-
>> нической_ проблемы.
TT> Изоляция транзакций - нетехническая проблема ?
Блин. Я тоже бываю тормозом, но есть же какие-то границы таймаутов...
Я говорю о чисто организационной проблеме. О том, что это не имеет
отношения к изоляции в частности и к серверу в целом - указано уже
сто раз. Так же, как и о том, что _здесь_ приемы борьбы будут
ровно одни и те же, вне зависимости от архитектуры. И о том, что
мы оба понимаем, как это делается (блокировкой на чтение, в _частности_).
Более, чем достаточно. А вот то, что это не более, чем затычка - ты
понимать категорически не желаешь. Hу и не надо.
TT> Ты поймешь всё же, что чтение дерева другой транзакцией "во время
TT> изменения" - есть чтение несогласованных данных и прямое нарушение
TT> изоляции ?
Да ни хрена. Либо чтения нет, либо есть - для uncommited. В любом
случае нарушение _текущего уровня_ изоляции _невозможно_ - иначе
это не сервер. Что до согласованности на бизнес-уровне - выбирай
_соответствующий_ уровень изоляции, и будет тебе щщастье. Кому я
это говорю?? А главное - зачем? Речь была HЕ ОБ ЭТОМ!!! Все, достал...
>> Угу. Толик Тенцер удаляет _нужную мне_ папку (а заодно и ряд других,
>> нужных, возможно, кому-то еще) и не видит в этом ничего
>> криминального...
TT> Сейчас договоримся, что удаление или изменение любых данных в БД
TT> "нужных, возможно, кому-то еще" - есть криминальная операция и БД её
TT> без административного регламента поддерживать не обязана.
Кто-то, если мне не изменяет склероз, вообще утверждал, что "данные -
есть ценная информация, и удалять ее нельзя". Это не цитата, смысл.
Меняем показания в зависимости от ситуации? Я же таким догматиком
никогда не был. Hо - удалять нечто, что нужно кому-то прямо сейчас?!
Обычный _административный_ бардак. И _технически_ ты его никогда
не устранишь...
TT> Да хоть и требует регламента, что я - за удалением всякой папки БД в
TT> single user переводить должен ?
Посмотри на себя со стороны... Если папка не нужна - она по определению
в not (а не single) used! В противном случае вопрос о ее нужности
придется реанимировать. Кстати, если тебе уж так хочется поговорить
о vs - на версионнике удаление легко пройдет в multiuser. Это так,
к слову.
TT> Хана всему бизнесу, БД не умеет папки удалять, а разработчики
TT> не велели иначе, 200 пользователей - отключиться немедленно,
TT> клиенты подождут, я щас папки удалять буду. Смешно ? Мне нет.
Какой тут смех - один из самых грамотных несет пургу даже в простых
вопросах... Плакать хочется :(
TT> Ага. Азы см. выше. И ниже - СУБД обязана воспрепятствовать чтению
TT> несогласованных данных другими транзакциями. Это даже не азы, это
TT> базис для азов. Если она этого делать не умеет - то разговоры
TT> разработчиков о "административном регламенте" - есть признак их
TT> несостоятельности в качестве разработчиков.
Hу-ну. Уровень uncommited для нас не существует, СУБД уже научилась
понимать согласованность на бизнес-уровне... Печально.
TT> Ты знаешь я наверно так и не пойму что такое "административная
TT> сериализация". Для меня это режим single user и, следовательно,
TT> бред.
И в твоем отделе все программисты _одновременно_ правят одну и ту
же функцию? Поскольку остальное для тебя бред...
Разговор слишком затянулся, его давно пора закончить. Сделаем это
хотя бы сейчас. Hо на почту отвечу, если захочешь.
---------------------------------------------
Владимир Павликов.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
