|
|
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat- DimaR onstat- Систематезируем условия абстрактной задачи. Есть наборы товаров с количеством в таблице, они уже закомичены. Нужно проводить по остаткам и по кассе эти наборы за одну транзакцию каждый, в паралельных сессиях, при том, что один одни товар встречается в 90% наборов. Такая постановка Вас устроит? в лобовую, select for update на кассах, и система будет вести себя так же ка и блокировочник. Нет не будет, читайте мое сообщение выше про установку SCN в слотах транзакций и поведении open в курсоре на update. Это плата за консистенность "на начало", которую мы обсуждали. Зато они класно формируют репорты. Ну не так все печально обстоит :) Вы можете, конечно, заставить сервер работать так, как Вы привыкли на блокировочниках. Но это булет не самый верный подход. В oracle, к примеру, выгоднее пользоваться тем, что он делает особенно хорошо - консистентными отчетами. То есть кассы регистрируют покупки (это insert) и ни о чем более не заботятся. Рабочие остатки в любой момент можно получить одним sql-запросом, сопоставив остатки от прошлой фиксации и товары, проведенные по кассе. В любой момент так же консистентно можно зафиксировать рабочие остатки и опираться уже на них. При этом вообще не требуется блокировка записей остатков при работе касс, а блокировка остатков очень кратковременна (на момент фиксации). Вот и расскажите теперь про преимущества блокировочника в супермаркете ;) onstat-То есть если какаято конкрентаня запись сейчас заблокирована, на следующий фетч она не пойдет а пойдет свободная, а через 5 фетчей ее уже закомитят.А каким образом он запоминает пропущенные записи и как потом к ним обращается? Допустим, есть табличка в 10 млн. строчек, под условия отбора попадает ~1млн, равномерно рассеянный по таблице 90% которых в текущий момент заблокированы. Запускаем запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 15:01 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ASCRUS Но однако проблемы это не снимает - кто сказал, что на момент фиксации остатков даже на месяц назад в этот момент у меня никто в БД не будет добавлять записи месячной давности ? Большой Босс. Если у вас данные за месяц не устаканиваются это всего лишь означает что надо отодвинуть дату фиксации еще дальше. До тех пор пока вероятность существования конкурентных транзакций не упадет до приемлемого уровня. Цель-то - избавиться от одновременных апдейтов. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 15:05 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Толком не пойму задачу, и мне что то лень втыкать :). ps. у нас остатки текущие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 15:14 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov ASCRUS Но однако проблемы это не снимает - кто сказал, что на момент фиксации остатков даже на месяц назад в этот момент у меня никто в БД не будет добавлять записи месячной давности ? Если у вас данные за месяц не устаканиваются это всего лишь означает что надо отодвинуть дату фиксации еще дальше. Да не надо тут никакой вероятностной мути. Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка. После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 15:26 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousДа не надо тут никакой вероятностной мути. Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка. После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет. Ага, заодно баланс откатить к примеру. Для таких случаев существуют проверки и перерасчеты задними числами - то что зафиксено никем просто так на автомате не откатывается, что в налоговой декларации, что в балансе, что по остаткам на складе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:03 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 ASCRUS Не понимаю, чего тут такую кашу развели с несчастным READ COMMITED - ведь написанно же, читаем закомиченные данные. Хотим второй раз те же данные считать, ставим REPEATABLEREAD, боимсе при повторном чтении новые записи схлопотать - ставим SERIALIZABLE. Все как написано в стандарте, работать в любом сервере должно одинаково по смыслу. Поправочка - работать должно в любом сервере одинаково по смыслу, но только если этот сервер нужный уровень изоляции есть :) А так да, если уровень изоляции есть - то (принципиальной) разницы быть не должно. Хотя как топик начался с того, что Гаря начал сравнивать разные сервера при разных уровнях изоляции, так оно и идет :). Разруха - она не в сортирах. Еще хотелось бы задать немного ламерский вопрос тем, кто работает с версионниками (так сказать для ликбеза) - как на версионнике обеспечить уровень изоляции SERIALIZABLE для гарантированного отсутствия фантомов. Да нету в версионниках сериалайзбла. Последний раз когда тема фантомов поднималась, кто-то из лагеря ораклоидов (помоему это был товарисч Глюк Казанский) начал плакать, а дескать как мы это реализуем без просадок производительности и прочие сопли. Ну, хозяин барин. Если не хотят работать медленно, то всегда остается альтернатива - работать неправильно :)) Вот и Йо начал песни петь про перфоманс и про бизнес-логику в супермаркетах :) Хотя, конечно, при наличии желания можно для каждого конкретного случая соорудить подобие сериалайзбла. Типа из огурца, петрушки и зеленого лука сделать себе маленького, но вполне съедобного Ктулху. ----------------------------------- 2 Yo!! блин еще один, непойму где вы (и остальные) увидели "чтения незакомиченных данных" Здесь При обсуждении ситуации "128 сессий каждая в своей транзакции проапдейтила, но еще не закоммитила", ты высказал, что блокировочник "будет видеть чужие изменения, читать заблокированые" - типо в противопоставление оракловому Read Commited. Возьми топор и попробуй вырубить :) ------------------------------------ 2 Gluk (Kazan) Gluk (Kazan)транзакция рушится на коммите. Специально для УМНЫХ аксессников - ТРАНЗАКЦИЯ не рушиться. Конкретный DML ловит Exception, вполне штатная ситуация (транзакции от этого не жарко и не холодно). Гыыыы... Товарисч Глюк, Вы тупой, или прикидываетесь? Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита. Претензии по абалденному частичному откату - конкретно для этого случая. Если не веришь, что транзакция может пасть именно на коммите, а не только на последнем стейтменте, то поинтересуйся у старших товарисчей. Или в библиотеку сходи. Если ты рассматриваешь какой-то другой случай - то и рассматривай его себе в тряпочку, ко мне то какие вопросы? У тебя есть документация по аксесу? Ага, есть. Вместе с аксессом Ну раз у тебя есть - ты и ищи. У меня, например, нету. Ни документации, ни аксеса :)) А раз оно у тебя оно есть вместе с аксесом, то можешь еще и эксперименты провести, если уж тебе так сильно "Хочется какта приобщиться". -------------------------- 2 andrey_anonymous Я так до сих пор и не смог осознать связи "версионник значит без блокировок" :( Ну откуда оно растет, кто-нибудь знает?! Точно так же можно сказать, что "блокировочник - это не значит без версий". Ну и о чем будем говорить? С одной стороны - гибрид, с другой стороны - гибрид. Не нужно обладать телепатическими способностями, чтобы понять, что под сравнением блокировочников с версионниками скорее всего подразумевается "чисто блокировочный" и "чисто версионный" подходы. Сравнивать гибриды разной степени гибридности никому не интересно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:08 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat- ... Рассказываю: При открытии курсора select for update oracle не вернет управление из open до тех пор пока для всех записей курсора в слоты транзакций в соответствующих блоках не будет проставлен SCN. Для того что бы проставить SCN предидущая транзакция изменяющая эту запись должна быть уже закомичена или откатана. ... Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable). Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:35 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
авторПретензии по абалденному частичному откату - конкретно для этого случая. тогда о каком вообще "частичном откате" при ошибке по commit речь??? Сами себе выдумываете какие-то странные "постановки задачи". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:36 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 kdv авторПретензии по абалденному частичному откату - конкретно для этого случая. тогда о каком вообще "частичном откате" при ошибке по commit речь??? Вот и я не понимаю - какой такой частичный откат??? Кто его выдумал, зачем он его выдумал, и почему ораклоиды начали приплетать сюда какие-то бредни типа "написать приладу", "последний стейтмент", "неявный сейв-поинт", и прочий цирк. Сами себе выдумываете какие-то странные "постановки задачи". Я выдумываю??? Это Гаря выдумал. Гарин пост сами найдете, или пальцем показать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:46 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛП Здесь При обсуждении ситуации "128 сессий каждая в своей транзакции проапдейтила, но еще не закоммитила", ты высказал, что блокировочник "будет видеть чужие изменения, читать заблокированые" - типо в противопоставление оракловому Read Commited. Возьми топор и попробуй вырубить :) зачем ? ИМХО это надо поставить в рамку и каждый раз тыкать лохов в нее :) попробую еще раз так чтоб даже последнему лоху было понятно: моя фраза делалась на 2 части "будет видеть чужие изменения" - думаю тут понятно что read commited у блокировочника (и в стандарте) не обещает не увидеть чужие, закомиченые изменения во время исполнения стейтмента (оракл же консистентное чтение обещает). и вторая часть "читать заблокированые" - это фича mssql где транзакция может прочитать запись, залоченую эксклюзивной блокировкой, чужой транзакции. ЛП Поправочка - работать должно в любом сервере одинаково по смыслу, но только если этот сервер нужный уровень изоляции есть :) А так да, если уровень изоляции есть - то (принципиальной) разницы быть не должно. мда ... 5 страниц разжевывали, разжевывали что не будет одинаково работать, хоть и имеют одинаковые названия уровней, но походу в пустую :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 16:49 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛП Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита. Претензии по абалденному частичному откату - конкретно для этого случая. Если не веришь, что транзакция может пасть именно на коммите, а не только на последнем стейтменте, то поинтересуйся у старших товарисчей. Или в библиотеку сходи. Я не являюсь большим специалистом в этом вопросе, и может "старшие" товарищи поправят, я знаю только один вариант когда транзакция вылетет на коммите, это если будет нарушен deferred constraint, тогда вроде откатится вся транзакция, но это вроде немного из другой оперы (наверное есть еще ньюансы в распределенных транзакциях) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:04 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛПДа нету в версионниках сериалайзбла. Последний раз когда тема фантомов поднималась, кто-то из лагеря ораклоидов (помоему это был товарисч Глюк Казанский) начал плакать, а дескать как мы это реализуем без просадок производительности и прочие сопли. Не песди, или сцылку дай. Не помню я такого ЛП Гыыыы... Товарисч Глюк, Вы тупой, или прикидываетесь? Четвертый раз повторяю - Гаря описал случай, когда ошибка ловится в момент коммита. Апять, же друк, пример нарисавать для Oracle руки не отсохнут ? ато складывается впечатление, что вы пи...бол ЛП А раз оно у тебя оно есть вместе с аксесом, то можешь еще и эксперименты провести, если уж тебе так сильно "Хочется какта приобщиться". Пальцем в доку ткнуть ламает ? Или по крайней мере сказать с какой ВЕРСИИ сие чудо появилось. Я все больше убеждаюсь в том, что кроме бла бла бла вы ничего не могете ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:07 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛПкакие-то бредни типа "написать приладу", Эти бредни фтваей галаве, трук. Где говорилось "написать" приладу ??? Прилада ЕСТЬ всегда (даже если это SQL+) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:12 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 Yo.!! моя фраза делалась на 2 части "будет видеть чужие изменения" - думаю тут понятно что read commited у блокировочника (и в стандарте) не обещает не увидеть чужие, закомиченые изменения Гыыы... с рассмотрения ста двадцати восьми незакоммиченных транзакций - плавный переход на чужие закомиченные изменения :). Ну да, оно конечно понятно, что так оно и подразумевалось с самого начала :)) Не отмазывайся, Йо. ---------------- 2 Gluk (Kazan) Не песди, или сцылку дай. Не помню я такого Гыыы... Оракл плохо на память влияет? "...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???" Тут Пальцем в доку ткнуть ламает ? Ломает, конечно. Кстати, сколько раз надо повторить, что у меня нет ни аксеса, ни доки к нему, прежде чем этот факт дойдет до пораженного ораклом мозга? :) Или по крайней мере сказать с какой ВЕРСИИ сие чудо появилось. Думаю, что с первой :) По крайней мере в Access 2.0 оно уже было. Эти бредни фтваей галаве, трук. Где говорилось "написать" приладу ??? Легко написать прикладу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:27 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛП2 Gluk (Kazan) Не песди, или сцылку дай. Не помню я такого Гыыы... Оракл плохо на память влияет? "...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???" Тут ЛП, Вы производите впечатление разумного человека. Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:32 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛП Легко написать прикладу По данной ссылке написано нечто, понятное только автору. Вы основываете на этом какие-либо выводы? Может, лучше уточнить у автора что именно он имел ввиду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:34 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ASCRUS andrey_anonymousДа не надо тут никакой вероятностной мути. Просто процедура, вливающая проводки в базу должна удалить все фиксации, помеченные более поздними датами, чем самая ранняя вливаемая проводка. После влива проводок можно опять сделать нужные фиксации, но это проблемы не предавляет. Ага, заодно баланс откатить к примеру. Для таких случаев существуют проверки и перерасчеты задними числами - то что зафиксено никем просто так на автомате не откатывается, что в налоговой декларации, что в балансе, что по остаткам на складе. Вы знаете хоть один способ не модифицировать баланс в случае появления начислений "задним числом"? Наверное, "блокировочник" волшебным образом сделает это за вас :) Нет? Тогда к чему это замечание? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:36 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChAВы, простите, о чем ? Мое комментарий относился только к утверждению Yo.!!, OK, понял. Я почему-то решил, что если ответ идет на цитату из моего письма, то он мне. Прошу прощения. ChAто Merle, в принципе, уже провел весьма убедительный эксперимент Спасибо, разобрался. К сожалению, текст оформлен чуть неудобно для восприятия человеком, у которого нет под рукой MSSQL, так что я пропустил его при ознакомлении. Хм. Ядерные реакторы ядерными реакторами... не знаю, может это вопрос привычки, но после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо. ChAАналогичность способа подразумевается как использование версионности, при котором не происходит чтения измененных данных, а не точное копия механизма. Признаться, сходу не нашел в первой названной ссылке описания названного Вами механизма (исключая возможность включить READ_COMMITTED_SHAPSHOT). Видимо, надо читать повнимательнее, так что ознакомлюсь позже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:40 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
AI onstat- ... Рассказываю: При открытии курсора select for update oracle не вернет управление из open до тех пор пока для всех записей курсора в слоты транзакций в соответствующих блоках не будет проставлен SCN. Для того что бы проставить SCN предидущая транзакция изменяющая эту запись должна быть уже закомичена или откатана. ... Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable). Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории? Абсолютно Ничем, кроме дополнительных накладных расходов и эскалации блокировок на таблице остатков. Чтобы получить консистентность данных на уровне транзакции (а не dml), как писал Андрей, в первом сообщенни на данной странице, нужно все делать в serializable. Или все, что он написал делается одним dml? типа update remains r set (cnt ......)=(select sum(fn)...... from tab1 t1.... group by.....) where <сумашедшая связка r и таблиц входящих в репорт) Хороший запросец для OLTP , не правда ли? Ихмо, чем дольше отягивается контроль логической целостности, тем больше необходимо ресурсов чтобы ее достичь. Ведь все сессии в ней нуждаются. А ресурсы сейчас дешевые :) Разруха она в головах, как правильно, кто то уже говорил здесь. 2 andrey_anonymous Задача была о "хлебе насущном", а не о супермаркете. Перевените ее наоборот в задачу выписки накладных по выдаче со склада и приеме товара на хранение суть от этого не изменится. По поводу пропуска записей решений может быть много, для каждого сервера свое, я пока не разработчик СУБД, когда им буду расскажу. зы Снова ушел работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:45 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 andrey_anonymous Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще. А какие выводы я должен был сделать из того высказывания и той дискуссии? В том дискуссии было высказано мнение, что в оракле нету уровня изоляции Serializable патамушта есть фантомы. Все с этим согласились. Какие выводы из этого я должен сделать? Теперь вот товарисч Глюк пытается открестится от авторства слов про всякие там слова про "просады производительности". Из этого я тоже должен какие-то выводы делать? По данной ссылке написано нечто, понятное только автору. Вы основываете на этом какие-либо выводы? Я делаю вывод что это - бредни. Но товарисч Глюк опять таки пытался авторство этих бредней приписать мне. С этим я согласиться не могу, потому что автор бредней совсем не я, но какие еще выводы я из этого должен сделать - обратно не понимаю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 17:46 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
softwarerХм. Ядерные реакторы ядерными реакторами... не знаю, может это вопрос привычки, но после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо.Согласен, для меня это тоже было неприятным фактом, пусть даже он и не противоречил формальному определению RC. К счастью, в большинстве случаев, достаточно его знать, чтобы понимать последствия такого поведения в конкретной ситуации и, соответственно, реагировать на него должным образом. Или не реагировать :) P.S. IMHO . Максимум производительности, в целом, лучше всего достигается тонкой настройкой, в том числе и хинтами. А "автоматика", а она и есть автоматика, она будет прекрасно работать в 90%(глядя на потолок) наиболее массовых и, как правило, более простых случаях, но в критичных ее лучше отключать и брать, что называется, дело в свои руки :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:14 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat- AI onstat-При открытии курсора select for update Разумеется. Это будет самое обычное ожидание освобождения блокировки. Затем будет получено текущее состояние записи (current read) и чтение или продолжится (при read commited), или даст ошибку (при serializable). Я писал, что dml получает данные последней доступной версии. Что тут противоречащего логике или теории?Абсолютно Ничем, кроме дополнительных накладных расходов и эскалации блокировок на таблице остатков.Что Вы имеете ввиду под эскалацией блокировок на таблице остатков? onstat-Чтобы получить консистентность данных на уровне транзакции (а не dml), как писал Андрей, в первом сообщенни на данной странице, нужно все делать в serializable .Думаю, это слишком сильное утверждение. Консистентность данных штука хорошая, но является лишь инструментом для достижения некоторых целей. Если задача "внести расход и обновить при этом таблицу остатков" не поддается переформулировке (и такое бывает), то оперируем: 1) консистентным набором проводок, подлежащих внесению. Мы их вставили, но не зафиксировали - никто кроме нас их еще не видит. 2) актуальным значением остатков на момент внесения - согласованность на уровне dml statement. 3) не так страшен черт (рестарт), как его малюют. Его еще надо суметь спровоцировать :) Но если нагрузочные тесты и в самом деле выявили данную проблему при обновлении группы записей , то можно снизить накладные расходы посредством пользовательской блокировки. Та же сериализация доступа. Т.е. создать паритетную по отношению к "блокировочнику" ситуацию достаточно просто. Следующий вопрос - как оптимизировать процесс, чтобы хлебушек не застопорил торговлю. Можно предложить несколько путей, но они будут одинаково эффективны (или одинаково неэффективны) что для блокировочника, что для версионника - посему оффтопик :) Причем организовать обновление "редких" групп товаров и отложить обновление востребованных можно и в oracle, причем не так уж и сложно, но "руками". С учетом Вашего дальнейшего замечания мне начинает казаться, что в "блокировочнике" дела обстоят не сильно лучше ;) onstat-Ихмо, чем дольше отягивается контроль логической целостности, тем больше необходимо ресурсов чтобы ее достичь. Ведь все сессии в ней нуждаются. Тут согласен. Но еще разумнее, на мой взгляд, нерперывно обеспечивать целостность, чтобы не приходилось ее достигать "потом". И тут очень часто помогает переформулировка задач. onstat-2 andrey_anonymous Задача была о "хлебе насущном", а не о супермаркете. Перевените ее наоборот в задачу выписки накладных по выдаче со склада и приеме товара на хранение суть от этого не изменится. Изменится. Контроль остатка - задачка интересная, поскольку провоцирует "горячие" точки в системе и в приведенном сценарии еще и тяжело поддается масштабированию (а если касс - 1000 штук? 10000?). Подходы есть, но они, как уже говорилось, будут схожи для любой СУБД. onstat-По поводу пропуска записей решений может быть много, для каждого сервера свое, я пока не разработчик СУБД, когда им буду расскажу. То есть Вы это придумали ?! Или все-таки есть надежные источники информации? Может, кто-нибудь из аудитории владеет вопросом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:21 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛП2 andrey_anonymous Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще. А какие выводы я должен был сделать из того высказывания и той дискуссии? В том дискуссии было высказано мнение, что в оракле нету уровня изоляции Serializable патамушта есть фантомы. Все с этим согласились. Какие выводы из этого я должен сделать? То есть Вы никаких выводов делать не стали. К чему тогда была эта ссылка? Просто показать, что Вы читали один из многочисленных топиков этого сайта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:24 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛПВот и я не понимаю - какой такой частичный откат??? Кто его выдумал, зачем он его выдумал, и почему ораклоиды начали приплетать сюда какие-то бредни типа "написать приладу", "последний стейтмент", "неявный сейв-поинт", и прочий цирк. а кто вообще выдумал какие-то действия при commit? Если НЕТ deferred constraints, то какая нафиг "ошибка при коммите", которая вообще не может возникнуть по определению? про "стейтменты" имеется в виду вот что: StartTransaction insert - ok insert - ok insert - облом Commit. Все. во время последнего insert оператор не выполнился. никаких роллбэков. Все что сделал этот insert, отменилось автоматической отменой savepoint. Изменения сделанные первыми двумя insert УЖЕ сохранены в БД. Commit лишь подтверждает вступление этих изменений в силу, а не "применяет их". softwarerно после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо. фигня это, если речь идет о read-committed. сам уровень изолированности неконсистентный в отношении чужих commit-изменений. Почему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем? Например, если некий select выполнен сейчас, секунду назад, или секундой позже? рекомендую почитать тут: http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:28 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 andrey_anonymous То есть Вы никаких выводов делать не стали. К чему тогда была эта ссылка? Абъисняйю Это сцылко к таму шта таварисч Глюк Козанскей папрасил сцылку. Глюк КозансейНе песди, или сцылку дай Вот йа и непезжу, и сцылко тоже откапал, рас уш у Глюка Козанскаво праблемы с памятию. ------------ Скажите пожалуйста, у Вас тоже мозг поражен ораклом? Или какие-либо другие причины, из-за которых затруднено понимание печатного текста? Или почему надо по три раза объяснять одно и то же??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:33 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34019745&tid=1553078]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
31ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 151ms |

| 0 / 0 |
