Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 14   вперед  Ctrl
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
kdv
softwarer
но после такого известия у меня было бы желание включить повсеместное использование repeatable read. Неконсистентный результат запроса - очень неуютная концепция, имхо.

фигня это, если речь идет о read-committed. сам уровень изолированности неконсистентный в отношении чужих commit-изменений. Почему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем?

Ну например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке.
А если хочется одновремено увидеть общую сумму по кассе + сумму товарных остатков и сопоставить с состоянием на утро, то вообще швах - мишшн импоссибл?
28 сен 06, 18:35    [3198835]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
kdv
а кто вообще выдумал какие-то действия при commit?

Абъисняйу...
Какийэ та деиствийа при камите выдумал Гаря, кагда расматривал нипаниатна какуйу субэдэ, в каторай фсе праверки и блакирофки правириайэт на камите.

И хуле фсе дружно на оракл переключились...
И хуле фсе дружно твердять "а вот так не бывает... но если деферед констрейнтс то бывает... но фсе равно не бывает, патамушта так не бывает никагда... но если дистрибьютед то бывает... но фсе равно не бывает"...
И хуле фсе какие-то сейв-поинты фспаминают...
28 сен 06, 18:51    [3198925]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
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 сен 06, 19:07    [3198991]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
andrey_anonymous

Что Вы имеете ввиду под эскалацией блокировок на таблице остатков?

Записи на которых уже стоит SCN транзакции, которая
в свою очередь ожидает(рестартует) запись занятую другой транзакцией
не могут быть обработаны третьей или червертой.


andrey_anonymous

С учетом Вашего дальнейшего замечания мне начинает казаться, что в "блокировочнике" дела обстоят не сильно лучше ;)


Страдают те блокировочники которые не могут ставить блокировку на уровне строки, а только на страницы(блоки).

andrey_anonymous

onstat-
Ихмо, чем дольше отягивается контроль логической целостности, тем больше необходимо ресурсов чтобы ее достичь.
Ведь все сессии в ней нуждаются.
Тут согласен.
Но еще разумнее, на мой взгляд, нерперывно обеспечивать целостность, чтобы не приходилось ее достигать "потом".
И тут очень часто помогает переформулировка задач.

Взаимно согласен.


andrey_anonymous

То есть Вы это придумали?!
Или все-таки есть надежные источники информации?
Может, кто-нибудь из аудитории владеет вопросом?


Надежных нет.
Я писал:

поиск остальных а также контроль уже установленных другими сессиями блокировок может
производится в фоновом режиме.


Я знаю, что Информикс не снимает блокировку
после освобождения записи, а уступает ее другой транзакции.
Логично предположить, что той которая в ней более всего нуждается(стоит в очереди на эту запись первой).
Если уступать некому, блокировка освобождается.
Точнее сказать не могу.
28 сен 06, 19:59    [3199097]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
onstat-
andrey_anonymous
Что Вы имеете ввиду под эскалацией блокировок на таблице остатков?

Записи на которых уже стоит SCN транзакции, которая
в свою очередь ожидает(рестартует) запись занятую другой транзакцией
не могут быть обработаны третьей или червертой.
???????
Заблокированная запись и есть заблокированная.
И в блокировочнике, и в версионнике.
Словосочетание "ожидает (рестартует) запись" просто лишено смысла.
Никакой "эскалации блокировок" в обсуждаемой (судя по ошибочным референсам на "SCN") СУБД нет, не надо выдумывать непонятно что.
onstat-
Страдают те блокировочники которые не могут ставить блокировку на уровне строки, а только на страницы(блоки).

И как спасают блокировки на уровне строки? Параллельные транзакции на них не останавливаются? :)
onstat-
[quot andrey_anonymous]
То есть Вы это придумали?!
Или все-таки есть надежные источники информации?
Может, кто-нибудь из аудитории владеет вопросом?

Надежных нет.
Я писал:
поиск остальных а также контроль уже установленных другими сессиями блокировок может производится в фоновом режиме.

Слова "в фоновом режиме" ничего не объясняют.
Вы, если я не ошибаюсь, говорили, что транзакция, наткнувшись на заблокированную строку, пропускает ее и идет себе дальше, а дойдя до конца - как-то "вспоминает" о пропущенных строках, возвращается и снова пытается их блокировать.
И вроде как это дает блокировочнику существенное преимущество перед версионником типа oracle, который, наткнувшись на заблокированну строку, будет ждать завершения конкурирующей транзакции.
Получается, что это утверждение пока что очень похоже плод фантазии.
28 сен 06, 21:59    [3199281]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
автор
Ну например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке.


Андрюша, кто такие вещи в read_committed считает, а? какой в дупу баланс в RC???
28 сен 06, 22:24    [3199317]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
kdv
автор
Ну например оно даст уверенность, что запрос, вычисляющий текущий баланс как сумму баланса на начало дня, начислений покажет именно баланс, а не погоду в Африке.
Андрюша, кто такие вещи в read_committed считает, а? какой в дупу баланс в RC???
А в чем проблема? Неконсистентный результат? Ой, а что это такое?
Может, мы что не так делаем?
kdvшечка, голубчик, подскажите как правильно, а то вот почему-то баланс сходится, зараза, копиночка в копиночку...
Наверное, мозг ораклом испорчен.
Потому что если у кого мозг ораклом не испорчен, то данные должны кривиться, а вся работа - останавливаться ибо стандарт, омммммм!

Ну вас нафиг, пойду я лучше пива тяпну за здоровье Ларри, да продлится его снапшот на долгие годы, ибо от многия геморроя пришедших к нему он избавил :)
28 сен 06, 22:59    [3199388]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67425
Блог
kdv
сам уровень изолированности неконсистентный в отношении чужих commit-изменений.

Хм. Долго думал над смыслом этой фразы.

kdv
Почему оператор внутри такого уровня должен быть консистентным, и какую "уверенность" это даст, и в чем? Например, если некий select выполнен сейчас, секунду назад, или секундой позже?

Даст уверенность, что селект, обращавшийся более чем к одной строке данных, вернет хоть сколько-нибудь осмысленный результат. Пусть на секунду раньше или на секунду позже, но осмысленный.

Для примера представьте себе, что есть две таблицы, связанные отношением "обязательная с обеих сторон один к одному". Представьте себе, что я решил выполнить к ним запрос с outer join. Так вот, описанная неконсистентность может привести к тому, что запрос вернет мне набор данных, прямо противоречащий действующему ограничению целостности. С моей точки зрения это... малость неудобно, назовем так.
28 сен 06, 23:30    [3199430]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
автор
Для примера представьте себе, что есть две таблицы, связанные отношением "обязательная с обеих сторон один к одному". Представьте себе, что я решил выполнить к ним запрос с outer join. Так вот, описанная неконсистентность может привести к тому, что запрос вернет мне набор данных, прямо противоречащий действующему ограничению целостности.


пример хороший, согласен. однако я все равно не считаю нестабильность курсора в RC чем-то страшным.
28 сен 06, 23:40    [3199442]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
kdv
пример хороший, согласен. однако я все равно не считаю нестабильность курсора в RC чем-то страшным.
Привычка - вторая натура.
29 сен 06, 00:02    [3199467]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 softwarer
С моей точки зрения это... малость неудобно, назовем так.

Неудобно штаны через голову одевать, а все остальное - исключительно дело привычки :)

На самом деле вопрос даже не филосовский, и исключительно простой.
Есть транзакция, работающая на уровне изоляции "Икс". Есть запрос, выполняющийся внутре этой транзакции. Какой уровень изоляции (по отношению к "чужим" изменениям) имеет этот запрос? Думаю, что не больше (но и не меньше) чем "Икс" родительской транзакции. Изолированность запроса в точности равна изолированности транзакции. Если, конечно, запрос не обернут во вложенную транзакцию с другим уровнем изоляции (случай гипотетический, ибо вложенные транзакции).

Если (вернее "так как") Read Commited разрешает (не запрещает) стейтментам транзакции видеть чужие закомиченные изменения - то и сам стейтмент (и части стейтмента) могут видеть чужие закомиченные изменения.
Если чужие закомиченные изменения не нужны, и даже противопоказаны - к вашим услугам всегда есть уровни изоляции выше RC.

Если я где-то не прав, то просьба меня где-то поправить.
29 сен 06, 04:36    [3199593]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andrey_anonymous
ЛП
2 Gluk (Kazan)
Не песди, или сцылку дай. Не помню я такого

Гыыы... Оракл плохо на память влияет?
"...Вы правы, если подобные аномалии недопустимы в Вашей задаче, следует совершать "дополнительные телодвижения". Теперь расскажите, как построить версионник без подобных аномалий и без отвратительных просадок по производительности при блокировании диапазонов ключей с соотвественно увеличивающеся вероятностью deadlock-ов ???"
Тут


ЛП, Вы производите впечатление разумного человека.
Я хотел бы услышать от Вас, какие именно выводы Вы сделали из данного высказывания Gluk (Kazan) в частности и из той дискуссии вообще.


+1 Не уловил как это соотносится с ТЕМОЙ текущей беседы
там мало мало об другом речь шла. И от тех слов я РАЗУМЕЕТСЯ отказываться не собираюсь

автор
Ломает, конечно.
Кстати, сколько раз надо повторить, что у меня нет ни аксеса, ни доки к нему, прежде чем этот факт дойдет до пораженного ораклом мозга? :)
...
Думаю, что с первой :)
По крайней мере в Access 2.0 оно уже было.


Коментарии излишни, вы пиздабол батенька, если где то слышали но показать немогете

автор
Легко написать прикладу


Уел, уел. На афтора посмотри. Или для тебя фсе ораклоиды на одно лицо ?

P.S. Вы проигнорировали вопрос относительно примера для Oracle, где ошибка возникает на commit-е (кроме случай отложенной проверки ограничений, эта экзотика отношения к разговору не имеет). Что ищо раз падтверждаит, что вы пиздабол и путаете теплое с мягким (Oracle с IB)
29 сен 06, 08:43    [3199798]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
andrey_anonymous
onstat-
andrey_anonymous
Что Вы имеете ввиду под эскалацией блокировок на таблице остатков?

Записи на которых уже стоит SCN транзакции, которая
в свою очередь ожидает(рестартует) запись занятую другой транзакцией
не могут быть обработаны третьей или червертой.
???????
Заблокированная запись и есть заблокированная.
И в блокировочнике, и в версионнике.
Словосочетание "ожидает (рестартует) запись" просто лишено смысла.
Никакой "эскалации блокировок" в обсуждаемой (судя по ошибочным референсам на "SCN") СУБД нет, не надо выдумывать непонятно что.


Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей.
Я это имел ввиду.
Эти записи уже не могут быть заблокированы какой либо еще транзакцией.
Много сессии поставили блокировки, но ни одна из них не начала обработку.
Все ждут комита одной транзакции.
29 сен 06, 10:35    [3200468]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32886

Привет, ЛП!
Ты пишешь:

ЛП
Л> Если (вернее "так как") Read Commited разрешает (не запрещает) стейтментам
Л> транзакции видеть чужие закомиченные изменения -
Л> то и сам стейтмент (и части стейтмента) могут видеть
Л> чужие закомиченные изменения.
Л> Если чужие закомиченные изменения не нужны,
Л> и даже противопоказаны - к вашим услугам всегда
Л> есть уровни изоляции выше RC.
как в анекдоте: "папа, а ты с кем это сейчас раговаривал?.."
не поймут они этого.
не хотят понимать.
и не могут.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

29 сен 06, 10:48    [3200554]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

Мимопроходящий

не поймут они этого.
не хотят понимать.

Может быть потому что у них есть только один уровень выше RC и
называется он SERIALIZABLE?..

Posted via ActualForum NNTP Server 1.3

29 сен 06, 11:02    [3200661]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
onstat-
Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей.
Я это имел ввиду.
Эти записи уже не могут быть заблокированы какой либо еще транзакцией.
Много сессии поставили блокировки, но ни одна из них не начала обработку.
Все ждут комита одной транзакции.

Я учитываю.
Я не вижу, чем тут поможет блокировочник.
29 сен 06, 11:35    [3200984]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
Dimitry Sibiryakov
Мимопроходящий

не поймут они этого.не хотят понимать.
Может быть потому что у них есть только один уровень выше RC и
называется он SERIALIZABLE?..

Скорее потому, что вообще не очень просто объяснить, почему следует предпочесть неудобную реализацию удобной.
Кивки на то, что "ибо формально не противоречит" как-то не убеждают :)
29 сен 06, 11:41    [3201043]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

Откуда:
Сообщений: 6941
andrey_anonymous
onstat-
Вы не учитываете то факт, что прежде чем наткнуться на заблокированную запись транзакция вероятнее всего уже удерживает определенное количство записей.
Я это имел ввиду.
Эти записи уже не могут быть заблокированы какой либо еще транзакцией.
Много сессии поставили блокировки, но ни одна из них не начала обработку.
Все ждут комита одной транзакции.

Я учитываю.
Я не вижу, чем тут поможет блокировочник.


Тем, что болкировочник ставит блокировку в момент fetch,
а не сразу на весь набор записей при открытии курсора.
Ихмо при этом не важно на каком уровень изоляции.
Блокаровка конкретной записи удерживается с момента fetch до комита( ролбека).

А в oracle ставит блокировку с момента open на весь набор записей.
Это плата за консистентность "на начало" о которой я уже писал.
29 сен 06, 11:52    [3201190]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67425
Блог
ЛП
Неудобно штаны через голову одевать, а все остальное - исключительно дело привычки :)

Наверное. Но не каждой привычкой хочется обзаводиться :)

ЛП
Если (вернее "так как") Read Commited разрешает (не запрещает) стейтментам транзакции видеть чужие закомиченные изменения - то и сам стейтмент (и части стейтмента) могут видеть чужие закомиченные изменения.

Если чужие закомиченные изменения не нужны, и даже противопоказаны - к вашим услугам всегда есть уровни изоляции выше RC.

Если я где-то не прав, то просьба меня где-то поправить.

В высказывании Вы правы, но оно немного не о том. И стейтмент, и части стейтмента отлично видят чужие закоммиченные изменения, и вопросов это не вызывает. Вопрос в том, что удобно, если стейтмент и его части видят их "под одним углом".

Уровни изоляции выше RC, конечно, есть, но тут есть одна неприятность: если подпрограмма неработоспособна на некотором уровне изоляции, она вообще говоря должна явно проверять текущий уровень изоляции. Мне неизвестен инструмент, в котором можно было бы удобно указать "вызов хранимки A на уровне изоляции Б должен трактоваться сервером как ошибка". Противный вариант - надеяться, что кто-то будет так любезен, что прочитает и запомнит комментарий, в котором написано "при вызове в RC функция может вернуть бред". Признаться, ни один из этих вариантов не представляется мне офигенно удобным и правильным, поэтому [в том числе поэтому] я предпочитаю минимизировать количество неRC-транзакций.
29 сен 06, 11:53    [3201195]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19912
onstat-
Я не вижу, чем тут поможет блокировочник.

Тем, что болкировочник ставит блокировку в момент fetch,
а не сразу на весь набор записей при открытии курсора.
Ихмо при этом не важно на каком уровень изоляции.
Блокаровка конкретной записи удерживается с момента fetch до комита( ролбека).
А в oracle ставит блокировку с момента open на весь набор записей.
Это плата за консистентность "на начало" о которой я уже писал.[/quot]
Таки не вижу разницы. Все равно курсор будет полностью обработан не ранее, чем будут заблокированы все необходимые строки.
Про пропуски блокировочником записей, заблокированных соседями, насколько я понял, Вы уже не говорите, соответственно и тот и другой будут благополучно ждать освобождения первой же встреченной заблокированной записи.
Так в чем выигрыш-то?
29 сен 06, 12:01    [3201274]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
softwarer
Мне неизвестен инструмент, в котором можно было бы удобно указать "вызов хранимки A на уровне изоляции Б должен трактоваться сервером как ошибка"
Это говорит лишь о том, что Вы с этим в своей практике не сталкивались, спасибо Oracle :)
В принципе, никто не мешает:
- установить уровень изоляции при входе в процедуру
- установить уровень изоляции при указании конкретного оператора
- установить уровень изоляции при указании конкретного таблицы
- ...

P.S. Собственно об этом уже неоднократно говорилось ранее, если есть проблема, практически всегда есть и решение.
P.P.S. В конце концов, в любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает.
29 сен 06, 14:49    [3202960]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67425
Блог
ChA
Это говорит лишь о том, что Вы с этим в своей практике не сталкивались, спасибо Oracle :)

Безусловно. У меня хватает причин. говорить Oracle спасибо.

ChA
В принципе, никто не мешает:
- установить уровень изоляции при входе в процедуру

Хм. Опуская рвущиеся наружу слова "идеологический бред - менять уровень изоляции по ходу транзакции", стоит отметить, что не только устанавливать при входе, а еще и восстанавливать старый при выходе, в том числе при выходе по exception-у. Довольно хлопотное занятие.

ChA
P.P.S. В конце концов, в любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает.

Можно. Но хлопотно и совершенно незачем. Из серии "удалять гланды бормашиной".
29 сен 06, 15:20    [3203220]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11376
softwarer
Хм. Опуская рвущиеся наружу слова "идеологический бред - менять уровень изоляции по ходу транзакции", стоит отметить, что не только устанавливать при входе, а еще и восстанавливать старый при выходе, в том числе при выходе по exception-у.
Упс. Почему бред, да еще и идеологический ? Можно пояснить более аргументированно ? И, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ?
*А восстанавливать не надо, при выходе из процедуры он автоматически возвращается к предыдущему, установленному до вызова, по крайней мере, в MSSQL, где так ведут себя практически все сессионные установки.
softwarer
ChA
в любой момент можно узнать текущий уровень изоляции и выдать ошибку, если он не устраивает.

Можно. Но хлопотно и совершенно незачем.
Нехлопотно, если понимаю, установить один раз и навсегда уровень serialzable ? Но, допустим, это сделает один клиент, а другой, не мудрствуя лукаво, его не установит. И что тогда ?
29 сен 06, 16:17    [3203665]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ChA
Упс. Почему бред, да еще и идеологический ? Можно пояснить более аргументированно ? И, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ?


Не деление бред, а перключение уровня изоляции в процессе самой транзакции. Это из цикла здесь играем, здесь не играем, а здесь рыбу заворачивали (с)

То есть именно так как любит делать M$
29 сен 06, 16:34    [3203830]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67425
Блог
ChA
Почему бред, да еще и идеологический ? Можно пояснить более аргументированно ?

Я сдерживаю эти слова именно потому, что не хочу сейчас уходить в обсуждение этой темы. Тезисно... имхо несложно построить пример, когда у пары транзакций меняется уровень изоляции, например, serializable -> read uncommitted -> serializable, в результате чего обе они нормально завершаются с результатами, решительно не вписывающимися в понятие serializable.

ChA
И, кстати, нельзя ли сделать еще более глубокий вывод, что деление на уровни изоляции - это тоже бред ?

Cмотря какую систему мышления использовать. Если логическую - из сказанного такого вывода не сделаешь. Если какую-либо другую - может быть и удастся.

ChA
А восстанавливать не надо, при выходе из процедуры он автоматически возвращается к предыдущему, установленному до вызова, по крайней мере, в MSSQL, где так ведут себя практически все сессионные установки.

Хм. Признаться, не понял, почему сессионные установки меняются при выходе из процедуры. Наверное в этом есть какая-то концепция, но звучит странно.

Что ж, половину задачи это решает.

ChA
Нехлопотно, если понимаю, установить один раз и навсегда уровень serialzable ?

Нехлопотно - использовать "консистентный read committed".

ChA
Но, допустим, это сделает один клиент, а другой, не мудрствуя лукаво, его не установит. И что тогда ?

Хм. Не очень понял, о чем Вы. Если моя программа, либо например триггер на logon сделает ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE, мне будет решительно наплевать, что там установил или не установил клиент. Собственно я не уверен, что клиент может "установить раз и навсегда уровень serializable".
29 сен 06, 16:57    [3204005]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить