|
Версионники и блокировочники
|
||
|---|---|---|
Участник
Откуда: бурятский тундрюк, эсквайр
Сообщения: 33 443 |
||
| 29.09.2006, 10:48 |
|
|
|
|
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
kdv softwarerно после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо. фигня это, если речь идет о read-committed. сам уровень изолированности неконсистентный в отношении чужих commit-изменений. Почему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем? Ну например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке. А если хочется одновремено увидеть общую сумму по кассе + сумму товарных остатков и сопоставить с состоянием на утро, то вообще швах - мишшн импоссибл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:35 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
kdvа кто вообще выдумал какие-то действия при commit? Абъисняйу... Какийэ та деиствийа при камите выдумал Гаря, кагда расматривал нипаниатна какуйу субэдэ, в каторай фсе праверки и блакирофки правириайэт на камите. И хуле фсе дружно на оракл переключились... И хуле фсе дружно твердять "а вот так не бывает... но если деферед констрейнтс то бывает... но фсе равно не бывает, патамушта так не бывает никагда... но если дистрибьютед то бывает... но фсе равно не бывает"... И хуле фсе какие-то сейв-поинты фспаминают... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 18:51 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Sorry за молдавский (old copy from sql.ru Sybase group): Delo ne v blokirovkax (hotia vse eti deadlocki locki lezut otsuda) voobshe govoria , a v tom chto net priviazki ko vremeni. Na vihode iz prostogo selecta ASE (da i DB2 poka) produsaet v multiuser srede v obshem sluchae meshaninu (po vremeni) kotoraja vozmozhno nikogda ne bila predstavlena ni v kakoi moment vremeni v tablitse i tolko ne davaja drugim rabotat (isolation level 3 realizovannii na blokirovkah ) mozho ee izbezhat (nu ne schitaj zamorochek s timestampami, @@spidami, temp teiblami) Resultat (po bolshomu schetu) zavisit ot takih faktorov kak CPU speed, indexi, plan optimizera i tp. i td. (tak natknulsia na blokirovku, zdesh(kak v traffice) , poluchil novoe znacheniee-radueshsia, a tak uspel shvatit staroe, tozhe neploho, ne beda chto ne consistent). Dostatochno bilo bi prosto imet 2 formi selecta (da i vse): 1. Ne uchitivaet voobshe izmenenii vo vremia prohoda query (kak Oracle) (chto-to tipa select from ... as of begin) 2. Uchitivaet vse zacomichennie izmenenia (kak dump Sybase-a). (chto-to tipa select from ... as of end) Vmesto etogo poluchaetsia ne to ni se ( kakieto starie znachenia, kakieto novie). Etto sovershenno neverno prosto s tocki zrenia zdravogo smisla. Po-vidimomu eto tianetsia ot rabot Gray v IBM (navrnoe vziali ot OS gde loks gorazdo koroche) , no facticheski on priznal chto bil ne prav (sm MSR-TR-95-51 A Critique of ANSI SQL Isolation Levels by Hal Berenson; Phil Bernstein; Jim Gray; Jim Melton; Elizabeth O'Neil; Patrick O'Neil June 1995 12p. http://research.microsoft.com/pubs/view.aspx?type=Technical%20Report&id=5) i Microsoft eto (MVCC) realizoval v Yukone, skolko zhe mozhno golovu ludiam (da i sebe) morochit realizacie vo obschem to neplohih isolation levelov s pomoshiu blokirovok bez ucheta point of time. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 19:07 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Что Вы имеете ввиду под эскалацией блокировок на таблице остатков? Записи на которых уже стоит SCN транзакции, которая в свою очередь ожидает(рестартует) запись занятую другой транзакцией не могут быть обработаны третьей или червертой. andrey_anonymous С учетом Вашего дальнейшего замечания мне начинает казаться, что в "блокировочнике" дела обстоят не сильно лучше ;) Страдают те блокировочники которые не могут ставить блокировку на уровне строки, а только на страницы(блоки). andrey_anonymous onstat-Ихмо, чем дольше отягивается контроль логической целостности, тем больше необходимо ресурсов чтобы ее достичь. Ведь все сессии в ней нуждаются. Тут согласен. Но еще разумнее, на мой взгляд, нерперывно обеспечивать целостность, чтобы не приходилось ее достигать "потом". И тут очень часто помогает переформулировка задач. Взаимно согласен. andrey_anonymous То есть Вы это придумали ?! Или все-таки есть надежные источники информации? Может, кто-нибудь из аудитории владеет вопросом? Надежных нет. Я писал: поиск остальных а также контроль уже установленных другими сессиями блокировок может производится в фоновом режиме. Я знаю, что Информикс не снимает блокировку после освобождения записи, а уступает ее другой транзакции. Логично предположить, что той которая в ней более всего нуждается(стоит в очереди на эту запись первой). Если уступать некому, блокировка освобождается. Точнее сказать не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 19:59 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat- andrey_anonymousЧто Вы имеете ввиду под эскалацией блокировок на таблице остатков? Записи на которых уже стоит SCN транзакции, которая в свою очередь ожидает(рестартует) запись занятую другой транзакцией не могут быть обработаны третьей или червертой. ??????? Заблокированная запись и есть заблокированная. И в блокировочнике, и в версионнике. Словосочетание "ожидает (рестартует) запись" просто лишено смысла. Никакой "эскалации блокировок" в обсуждаемой (судя по ошибочным референсам на "SCN") СУБД нет, не надо выдумывать непонятно что. onstat-Страдают те блокировочники которые не могут ставить блокировку на уровне строки, а только на страницы(блоки). И как спасают блокировки на уровне строки? Параллельные транзакции на них не останавливаются? :) onstat-[quot andrey_anonymous] То есть Вы это придумали ?! Или все-таки есть надежные источники информации? Может, кто-нибудь из аудитории владеет вопросом? Надежных нет. Я писал: поиск остальных а также контроль уже установленных другими сессиями блокировок может производится в фоновом режиме. Слова "в фоновом режиме" ничего не объясняют. Вы, если я не ошибаюсь, говорили, что транзакция, наткнувшись на заблокированную строку, пропускает ее и идет себе дальше, а дойдя до конца - как-то "вспоминает" о пропущенных строках, возвращается и снова пытается их блокировать. И вроде как это дает блокировочнику существенное преимущество перед версионником типа oracle, который, наткнувшись на заблокированну строку, будет ждать завершения конкурирующей транзакции. Получается, что это утверждение пока что очень похоже плод фантазии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 21:59 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
авторНу например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке. Андрюша, кто такие вещи в read_committed считает, а? какой в дупу баланс в RC??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 22:24 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
kdv авторНу например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке.Андрюша, кто такие вещи в read_committed считает, а? какой в дупу баланс в RC???А в чем проблема? Неконсистентный результат? Ой, а что это такое? Может, мы что не так делаем? kdvшечка, голубчик, подскажите как правильно, а то вот почему-то баланс сходится, зараза, копиночка в копиночку... Наверное, мозг ораклом испорчен. Потому что если у кого мозг ораклом не испорчен, то данные должны кривиться, а вся работа - останавливаться ибо стандарт, омммммм! Ну вас нафиг, пойду я лучше пива тяпну за здоровье Ларри, да продлится его снапшот на долгие годы, ибо от многия геморроя пришедших к нему он избавил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 22:59 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
kdvсам уровень изолированности неконсистентный в отношении чужих commit-изменений. Хм. Долго думал над смыслом этой фразы. kdvПочему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем? Например, если некий select выполнен сейчас, секунду назад, или секундой позже? Даст уверенность, что селект, обращавшийся более чем к одной строке данных, вернет хоть сколько-нибудь осмысленный результат. Пусть на секунду раньше или на секунду позже, но осмысленный. Для примера представьте себе, что есть две таблицы, связанные отношением "обязательная с обеих сторон один к одному". Представьте себе, что я решил выполнить к ним запрос с outer join. Так вот, описанная неконсистентность может привести к тому, что запрос вернет мне набор данных, прямо противоречащий действующему ограничению целостности. С моей точки зрения это... малость неудобно, назовем так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 23:30 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
авторДля примера представьте себе, что есть две таблицы, связанные отношением "обязательная с обеих сторон один к одному". Представьте себе, что я решил выполнить к ним запрос с outer join. Так вот, описанная неконсистентность может привести к тому, что запрос вернет мне набор данных, прямо противоречащий действующему ограничению целостности. пример хороший, согласен. однако я все равно не считаю нестабильность курсора в RC чем-то страшным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2006, 23:40 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
kdvпример хороший, согласен. однако я все равно не считаю нестабильность курсора в RC чем-то страшным. Привычка - вторая натура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 00:02 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2 softwarer С моей точки зрения это... малость неудобно, назовем так. Неудобно штаны через голову одевать, а все остальное - исключительно дело привычки :) На самом деле вопрос даже не филосовский, и исключительно простой. Есть транзакция, работающая на уровне изоляции "Икс". Есть запрос, выполняющийся внутре этой транзакции. Какой уровень изоляции (по отношению к "чужим" изменениям) имеет этот запрос? Думаю, что не больше (но и не меньше) чем "Икс" родительской транзакции. Изолированность запроса в точности равна изолированности транзакции. Если, конечно, запрос не обернут во вложенную транзакцию с другим уровнем изоляции (случай гипотетический, ибо вложенные транзакции). Если (вернее "так как") Read Commited разрешает (не запрещает) стейтментам транзакции видеть чужие закомиченные изменения - то и сам стейтмент (и части стейтмента) могут видеть чужие закомиченные изменения. Если чужие закомиченные изменения не нужны, и даже противопоказаны - к вашим услугам всегда есть уровни изоляции выше RC. Если я где-то не прав, то просьба меня где-то поправить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 04:36 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous ЛП2 Gluk (Kazan) Не песди, или сцылку дай. Не помню я такого Гыыы... Оракл плохо на память влияет? "...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???" Тут ЛП, Вы производите впечатление разумного человека. Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще. +1 Не уловил как это соотносится с ТЕМОЙ текущей беседы там мало мало об другом речь шла. И от тех слов я РАЗУМЕЕТСЯ отказываться не собираюсь авторЛомает, конечно. Кстати, сколько раз надо повторить, что у меня нет ни аксеса, ни доки к нему, прежде чем этот факт дойдет до пораженного ораклом мозга? :) ... Думаю, что с первой :) По крайней мере в Access 2.0 оно уже было. Коментарии излишни, вы пиздабол батенька, если где то слышали но показать немогете авторЛегко написать прикладу Уел, уел. На афтора посмотри. Или для тебя фсе ораклоиды на одно лицо ? P.S. Вы проигнорировали вопрос относительно примера для Oracle, где ошибка возникает на commit-е (кроме случай отложенной проверки ограничений, эта экзотика отношения к разговору не имеет). Что ищо раз падтверждаит, что вы пиздабол и путаете теплое с мягким (Oracle с IB) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 08:43 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous onstat- andrey_anonymousЧто Вы имеете ввиду под эскалацией блокировок на таблице остатков? Записи на которых уже стоит SCN транзакции, которая в свою очередь ожидает(рестартует) запись занятую другой транзакцией не могут быть обработаны третьей или червертой. ??????? Заблокированная запись и есть заблокированная. И в блокировочнике, и в версионнике. Словосочетание "ожидает (рестартует) запись" просто лишено смысла. Никакой "эскалации блокировок" в обсуждаемой (судя по ошибочным референсам на "SCN") СУБД нет, не надо выдумывать непонятно что. Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей. Я это имел ввиду. Эти записи уже не могут быть заблокированы какой либо еще транзакцией. Много сессии поставили блокировки, но ни одна из них не начала обработку. Все ждут комита одной транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 10:35 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Привет, ЛП! Ты пишешь: ЛПЛ> Если (вернее "так как") Read Commited разрешает (не запрещает) стейтментам Л> транзакции видеть чужие закомиченные изменения - Л> то и сам стейтмент (и части стейтмента) могут видеть Л> чужие закомиченные изменения. Л> Если чужие закомиченные изменения не нужны, Л> и даже противопоказаны - к вашим услугам всегда Л> есть уровни изоляции выше RC.как в анекдоте: "папа, а ты с кем это сейчас раговаривал?.." не поймут они этого. не хотят понимать. и не могут. -- With best regards, Мимопроходящий. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 10:48 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий не поймут они этого. не хотят понимать. Может быть потому что у них есть только один уровень выше RC и называется он SERIALIZABLE?.. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 11:02 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat-Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей. Я это имел ввиду. Эти записи уже не могут быть заблокированы какой либо еще транзакцией. Много сессии поставили блокировки, но ни одна из них не начала обработку. Все ждут комита одной транзакции. Я учитываю. Я не вижу, чем тут поможет блокировочник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 11:35 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov Мимопроходящий не поймут они этого.не хотят понимать. Может быть потому что у них есть только один уровень выше RC и называется он SERIALIZABLE?.. Скорее потому, что вообще не очень просто объяснить, почему следует предпочесть неудобную реализацию удобной. Кивки на то, что "ибо формально не противоречит" как-то не убеждают :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 11:41 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous onstat-Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей. Я это имел ввиду. Эти записи уже не могут быть заблокированы какой либо еще транзакцией. Много сессии поставили блокировки, но ни одна из них не начала обработку. Все ждут комита одной транзакции. Я учитываю. Я не вижу, чем тут поможет блокировочник. Тем, что болкировочник ставит блокировку в момент fetch, а не сразу на весь набор записей при открытии курсора. Ихмо при этом не важно на каком уровень изоляции. Блокаровка конкретной записи удерживается с момента fetch до комита( ролбека). А в oracle ставит блокировку с момента open на весь набор записей. Это плата за консистентность "на начало" о которой я уже писал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 11:52 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ЛПНеудобно штаны через голову одевать, а все остальное - исключительно дело привычки :) Наверное. Но не каждой привычкой хочется обзаводиться :) ЛПЕсли (вернее "так как") Read Commited разрешает (не запрещает) стейтментам транзакции видеть чужие закомиченные изменения - то и сам стейтмент (и части стейтмента) могут видеть чужие закомиченные изменения. Если чужие закомиченные изменения не нужны, и даже противопоказаны - к вашим услугам всегда есть уровни изоляции выше RC. Если я где-то не прав, то просьба меня где-то поправить. В высказывании Вы правы, но оно немного не о том. И стейтмент, и части стейтмента отлично видят чужие закоммиченные изменения, и вопросов это не вызывает. Вопрос в том, что удобно, если стейтмент и его части видят их "под одним углом". Уровни изоляции выше RC, конечно, есть, но тут есть одна неприятность: если подпрограмма неработоспособна на некотором уровне изоляции, она вообще говоря должна явно проверять текущий уровень изоляции. Мне неизвестен инструмент, в котором можно было бы удобно указать "вызов хранимки A на уровне изоляции Б должен трактоваться сервером как ошибка". Противный вариант - надеяться, что кто-то будет так любезен, что прочитает и запомнит комментарий, в котором написано "при вызове в RC функция может вернуть бред". Признаться, ни один из этих вариантов не представляется мне офигенно удобным и правильным, поэтому [в том числе поэтому] я предпочитаю минимизировать количество неRC-транзакций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 11:53 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
onstat-Я не вижу, чем тут поможет блокировочник. Тем, что болкировочник ставит блокировку в момент fetch, а не сразу на весь набор записей при открытии курсора. Ихмо при этом не важно на каком уровень изоляции. Блокаровка конкретной записи удерживается с момента fetch до комита( ролбека). А в oracle ставит блокировку с момента open на весь набор записей. Это плата за консистентность "на начало" о которой я уже писал.[/quot] Таки не вижу разницы. Все равно курсор будет полностью обработан не ранее, чем будут заблокированы все необходимые строки. Про пропуски блокировочником записей, заблокированных соседями, насколько я понял, Вы уже не говорите, соответственно и тот и другой будут благополучно ждать освобождения первой же встреченной заблокированной записи. Так в чем выигрыш-то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 12:01 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
softwarerМне неизвестен инструмент, в котором можно было бы удобно указать "вызов хранимки A на уровне изоляции Б должен трактоваться сервером как ошибка"Это говорит лишь о том, что Вы с этим в своей практике не сталкивались, спасибо Oracle :) В принципе, никто не мешает: - установить уровень изоляции при входе в процедуру - установить уровень изоляции при указании конкретного оператора - установить уровень изоляции при указании конкретного таблицы - ... P.S. Собственно об этом уже неоднократно говорилось ранее, если есть проблема, практически всегда есть и решение. P.P.S. В конце концов, в любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 14:49 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChAЭто говорит лишь о том, что Вы с этим в своей практике не сталкивались, спасибо Oracle :) Безусловно. У меня хватает причин. говорить Oracle спасибо. ChAВ принципе, никто не мешает: - установить уровень изоляции при входе в процедуру Хм. Опуская рвущиеся наружу слова "идеологический бред - менять уровень изоляции по ходу транзакции", стоит отметить, что не только устанавливать при входе, а еще и восстанавливать старый при выходе, в том числе при выходе по exception-у. Довольно хлопотное занятие. ChAP.P.S. В конце концов, в любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает. Можно. Но хлопотно и совершенно незачем. Из серии "удалять гланды бормашиной". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 15:20 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
softwarerХм. Опуская рвущиеся наружу слова "идеологический бред - менять уровень изоляции по ходу транзакции", стоит отметить, что не только устанавливать при входе, а еще и восстанавливать старый при выходе, в том числе при выходе по exception-у.Упс. Почему бред, да еще и идеологический ? Можно пояснить более аргументированно ? И, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ? * А восстанавливать не надо, при выходе из процедуры он автоматически возвращается к предыдущему, установленному до вызова, по крайней мере, в MSSQL, где так ведут себя практически все сессионные установки. softwarer ChAв любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает. Можно. Но хлопотно и совершенно незачем.Нехлопотно, если понимаю, установить один раз и навсегда уровень serialzable ? Но, допустим, это сделает один клиент, а другой, не мудрствуя лукаво, его не установит. И что тогда ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 16:17 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChAУпс. Почему бред, да еще и идеологический ? Можно пояснить более аргументированно ? И, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ? Не деление бред, а перключение уровня изоляции в процессе самой транзакции. Это из цикла здесь играем, здесь не играем, а здесь рыбу заворачивали (с) То есть именно так как любит делать M$ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 16:34 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChAПочему бред, да еще и идеологический ? Можно пояснить более аргументированно ? Я сдерживаю эти слова именно потому, что не хочу сейчас уходить в обсуждение этой темы. Тезисно... имхо несложно построить пример, когда у пары транзакций меняется уровень изоляции, например, serializable -> read uncommitted -> serializable, в результате чего обе они нормально завершаются с результатами, решительно не вписывающимися в понятие serializable. ChAИ, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ? Cмотря какую систему мышления использовать. Если логическую - из сказанного такого вывода не сделаешь. Если какую-либо другую - может быть и удастся. ChAА восстанавливать не надо, при выходе из процедуры он автоматически возвращается к предыдущему, установленному до вызова, по крайней мере, в MSSQL, где так ведут себя практически все сессионные установки. Хм. Признаться, не понял, почему сессионные установки меняются при выходе из процедуры . Наверное в этом есть какая-то концепция, но звучит странно. Что ж, половину задачи это решает. ChAНехлопотно, если понимаю, установить один раз и навсегда уровень serialzable ? Нехлопотно - использовать "консистентный read committed". ChAНо, допустим, это сделает один клиент, а другой, не мудрствуя лукаво, его не установит. И что тогда ? Хм. Не очень понял, о чем Вы. Если моя программа, либо например триггер на logon сделает ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE, мне будет решительно наплевать, что там установил или не установил клиент. Собственно я не уверен, что клиент может "установить раз и навсегда уровень serializable". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2006, 16:57 |
|
||
|
|
start [/forum/topic.php?fid=35&msg=34020251&tid=1553078]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 351ms |
| 0 / 0 |
