 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 04 Jan 2003 19:11:00 To : Sergey Prach Subject : Re: Синхронизация доступа к БД -------------------------------------------------------------------------------- Hello, Sergey Prach! You wrote to Vladimir Pavlikov on Thu, 26 Dec 2002 23:16:01 +0000 (UTC): >> "Перевод денег с одного счета на другой" - это _одна_ операция. >> Разумеется, проводится в одной транзакции. Это не "тысячи операций SP> Так разумеется или желательно?! Второе утверждение как бы ну SP> никак не поглощает первое? Откатись по треду : операция всегда в одной транзакции, много опера- ций _желательно_ не пихать все в одну транзакцию. Т.е. речь о разном - никаких поглощений. SP> Хорошо, давай без "ну". Володенька, приведи пожалуйста пример SP> реализации моментального SNAPSHOT-а для БД в 10-20Гб, или хотя бы SP> что бы он был более эффективен чем SERIALIZABLE, когда модификации SP> подвергаются около 20% данных. Тебе уже несколько раз объясняли (не только я), что на версионнике "снимок" не зависит от : 1. размера базы 2. Объема модификаций 3. всегда мгновенный Т.е. твой вопрос - бессмысленен. SP> Володенька, совместный доступ на модификацию конкурентных даных SP> - это всегда проблема, хоть для версионников, хоть для _Таких_ версионников в природе не существует, все мне известные верси- онны лишь по чтению. Т.е. здесь разницы архитектур нет. SP> блокировочников. И при решениии этой проблемы всегда одна транзакция SP> погибает. Только у блокировочника эта одна из транзакций погибает SP> еще только при первой попытке модифицировать конкурентную область SP> данных. А у блокировочника в момент фазы комит. Иначе невозможно SP> удерживать БД в непротиворечивом состоянии, это давным давно SP> доказано как теоретически так и практически. Ерунда. Это стратегия обработки (пессиместическая или оптимистическая), и обе реализуемы в обоих архитектурах. Другое дело, что тяжесть реали- зации разная. А вот какая стратегия лучше _для "данного" использования_ - определяется _только_ использованием. К сожалению, этот параметр СУБД есть для каждой из них константа для любого сервера :( SP> Так вот и в споре про блокировочник и версионник: если в первом SP> одна из транзакций практически всегда сдыхает, и только в редких SP> случаях (dead lock) - обе, то в версионнике приведение всех версий в SP> соотвтетстве - всегда головная боль и всегда довольно большие SP> затраты на дисковый обмен. Я тебе на полном серьезе предлагаю отдохнуть от темы.... Хотя бы потому, что : "Скажу честно, что я счтал, что при dead lock погибают обе трназкции, но логически я понимал, что даже с теретичской точки зрения достаточо гибели одной, а уж с практичекой и подавно. А в доку глянуть за всем этим новогодним дурдомом - половина клиентов накупило себе домой компьюетры и почему-то считают, что я всю жизнь мечтал ублажить их чадо в области настройки компьютера. Посему в доке искать подтвежения/опровержения времени не хватило." Признаться, не ожидал от тебя :( - это же основы, элементар- щина... Займись изучением того, что _сегодня_ используешь - это лучше, чем рассуждать на темы, в которых тем более не разобрался. Да и пользы больше. --------------------------------------------- Владимир Павликов. -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/64886e78ce1c.html, оценка из 5, голосов 10
|
|
|