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

Откуда: Москва
Сообщений: 11377
Gluk (Kazan)
Не деление бред, а перключение уровня изоляции в процессе самой транзакции. Это из цикла здесь играем, здесь не играем, а здесь рыбу заворачивали (с)

То есть именно так как любит делать M$
Я просил - аргументированно. Хорошо, тогда ответьте на такой вопрос - почему в стандарте ANSI есть оператор SET TRANSACTION, если его применение идеологически неверно ? Кроме того, по стандартам ANSI рекомендуется вообще не допускать возможностей работы вне транзакций. В Informix, если правильно помню, он так и назывался ANSI mode, у MSSQL - implicit. Для такого режима вообще нет понятия начала транзакции, так как вы всегда работаете в транзакции. Единственное, что можно, это делать COMMIT или ROLLBACK, после которой автоматически начинается следующая транзакция. В этом режиме тоже будем запрещать менять уровень транзакций ?
*И, пожалуйста, больше не надо лозунгов про M$, не на демонстрации. На уровне "маздай" общаться в дальнейшем не намерен.
sotwarer
имхо несложно построить пример, когда у пары транзакций меняется уровень изоляции, например, serializable -> read uncommitted -> serializable, в результате чего обе они нормально завершаются с результатами, решительно не вписывающимися в понятие serializable.
Тогда зачем вообще существует режим RU ? :)
Пример, наверное, построить можно, при условии взаимодействия данных между этими участками кода. Но возможность написание неверного кода вряд ли может говорить об идеологической неверности языка, разве нет ? Это могут быть совершенно изолированные участки, но выполняемые в рамках одной транзакции. Вас ведь не смущают автономные транзакции ?
sotwarer
Признаться, не понял, почему сессионные установки меняются при выходе из процедуры.
Они возвращаются к своему исходному состоянию, а внутри процедуры я волен устанавливать их в другое состояние, которое мне кажется более подходящим в конкретной ситуации. К ним относятся не только SET TRANSACTION LEVEL, но и многие другие. Если правда интересно, то посмотрите в BOL почти все начинающееся с SET.
sotwarer
Нехлопотно - использовать "консистентный read committed"
Это лишь потому, что он в Oracle такой, фактически эвивалентный RR. Таким образом, будет также нехлопотно поставить в MSSQL уровень RR.
sotwarer
Не очень понял, о чем Вы. Если моя программа, либо например триггер на logon сделает ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE, мне будет решительно наплевать, что там установил или не установил клиент.
И что ? Клиент, ничтожно сумняшеся, не сможет поставить другой уровень изоляции ? Он может совершенно не предполагать, что некий триггер на logon уже его устанавил. Более того, по задаче ему нужен другой уровень изоляции. К одной и той же БД может быть подключено несколько разных клиентов, написанных разными командами и решающими совершенно разные подзадачи, и у каждого из них могут быть свои требования.
29 сен 06, 17:55    [3204372]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
hvlad
Member

Откуда:
Сообщений: 11553
ChA
Gluk (Kazan)
Не деление бред, а перключение уровня изоляции в процессе самой транзакции. Это из цикла здесь играем, здесь не играем, а здесь рыбу заворачивали (с)

То есть именно так как любит делать M$
Я просил - аргументированно. Хорошо, тогда ответьте на такой вопрос - почему в стандарте ANSI есть
оператор SET TRANSACTION, если его применение идеологически неверно ?

SQL2002 (Working Draft)
16.2 <set transaction statement>
Function
Set the characteristics of the next SQL-transaction for the SQL-agent.
NOTE 415 – This statement has no effect on any SQL-transactions subsequent to
the next SQL-transaction.
Я, честно говоря, тоже в шоке от того, что MSSQL позволяет менять уровень изоляции тр-ций на лету

ChA
Кроме того, по стандартам ANSI рекомендуется вообще не допускать возможностей работы вне транзакций.
А никто и не допускает :)
29 сен 06, 18:32    [3204530]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
Тогда зачем вообще существует режим RU ? :)

Для работы транзакций, которым нужен именно такой уровень изоляции.

ChA
Но возможность написание неверного кода вряд ли может говорить об идеологической неверности языка, разве нет ?

Неудачная в данном случае аналогия, скрывающее суть.

Транзакция как понятие является чем-то вроде контракта: "если вы соблюдаете определенные правила, мы гарантируем такой-то результат". В обсуждаемом случае этот контракт нарушается, результат не гарантирован. Для ЯП такой контрактной схемой является, например, поведение конкретных операторов. И для соблюдения этого контракта точно так же накладываются ограничения, например запрет goto внутрь цикла или в другую подпрограмму.

ChA
Вас ведь не смущают автономные транзакции ?

Не смущают. Именно потому, что они автономные, и независимы от основной. Автономная транзакция - это просто удобный способ выполнить то, ради чего в противном случае пришлось бы поднимать второе соединение с БД.

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

Боюсь, быстро не найду, поэтому позволю себе задать вопрос: это относится к любому вызову процедуры или только к внешнему? То есть, если я вызываю процедуру А, из нее вызывается процедура Б - в какие моменты будет осуществляться возврат? И если после возврата из Б, то вернется ли он именно к сессионным установкам или же к текущим для А?

ChA
Это лишь потому, что он в Oracle такой, фактически эвивалентный RR.

Он заметно слабее RR, но безусловно, именно поэтому. Поэтому я и сказал начальную фразу - обнаружив неконсистентность селекта, я бы немедленно испытал желание работать в дефолтовом RR.

ChA
Таким образом, будет также нехлопотно поставить в MSSQL уровень RR.

Хм. Тогда я не очень понимаю, что мы обсуждаем, если ветка началась именно с моей фразы, что я бы испытал желание именно это и сделать.

ChA
И что ? Клиент, ничтожно сумняшеся, не сможет поставить другой уровень изоляции ?

Как именно он сможет это сделать?

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

Хм. Простите, не стоит ли читать повнимательнее? На всякий случай, напишу еще раз:

ALTER SESSION set isolation_level = serializable

И при чем тут разные клиенты разных команд разных задач?
29 сен 06, 18:33    [3204532]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
hvlad
SQL2002 (Working Draft)
16.2 <set transaction statement>
Function
Set the characteristics of the next SQL-transaction for the SQL-agent.
NOTE 415 – This statement has no effect on any SQL-transactions subsequent to
the next SQL-transaction.
Спасибо ! Это вполне убедительно, насколько я понимаю английский. Значит MS в этом вопросе не придерживается стандарта. Жаль, так как это бывает иногда удобно, ведь для MSSQL это всего лишь обозначает продолжительность и диапазон накладываемых блокировок при чтении данных. Если отнять возможность играть уровнем изоляции, значит придется устанавливать уровень транзакций на допустимый минимум, и чаще использовать хинты, находящиеся вне юрисдикции стандартов. Увы...
sotwarer
это относится к любому вызову процедуры или только к внешнему? То есть, если я вызываю процедуру А, из нее вызывается процедура Б - в какие моменты будет осуществляться возврат? И если после возврата из Б, то вернется ли он именно к сессионным установкам или же к текущим для А?
Установки возвращаются к тем, которые были на момент запуска процедуры. Т.е., если из A была вызвана B, то по окончанию B и возврата управления в A будут восстановлены все установки для A до запуска B. Иллюстрация такого поведения для TIL
CREATE PROC GCTIL @pNote varchar(255)
AS SELECT @pNote AS Note, [Value] AS TIL
FROM #t
WHERE [Set option] = 'isolation level'
GO

CREATE PROC CTIL @pNote varchar(255)
AS 
CREATE TABLE #t ([Set option] varchar(255), [Value] varchar(255))
INSERT INTO #t
EXEC ('DBCC USEROPTIONS')
EXEC GCTIL @pNote
GO

CREATE PROC b
AS 
EXEC CTIL 'b - init'
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
EXEC CTIL 'b - after set'
GO
CREATE PROC a
AS 
EXEC CTIL 'a - init'
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
EXEC CTIL 'a - after set'
EXEC b
EXEC CTIL 'a - after exec b'
GO

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
EXEC CTIL 'Start'
EXEC a
EXEC CTIL 'after exec a'
GO

DROP PROC a, b, ctil, gctil
Упрощенный вывод
Start : read uncommitted
a - init : read uncommitted
a - after set : read committed
b - init : read committed
b - after set : repeatable read
a - after exec b : read committed
after exec a : read uncommitted

softwarer
не стоит ли читать повнимательнее?
Извините, что не знаю, как работает ALTER SESSION set isolation_level. Судя по Вашей экспрессии, он заставляет любого клиента при подключении к Oracle иметь один единственный заранее установленный эээ...администратором уровень изоляции. Типа, у меня не забалуешь. Однако, тоже подход, иногда полезно.
*И, пожалуйста, больше так не надо, я же не тыкаю Вам в нос, что Вы не знаете, как работают установки сессии в MSSQL или какой-либо из его операторов.
29 сен 06, 20:18    [3204841]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
А можете показать по dml-операции между set transaction?
Оракель, for ex, обругает нехорошими словами, поскольку set transaction обязан быть первым statement в транзакции.
29 сен 06, 21:31    [3205091]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
Установки возвращаются к тем, которые были на момент запуска процедуры. Т.е., если из A была вызвана B, то по окончанию B и возврата управления в A будут восстановлены все установки для A до запуска B.

То есть стек. Да, наверное это удобно.

ChA
Извините, что не знаю, как работает ALTER SESSION set isolation_level. Судя по Вашей экспрессии, он заставляет любого клиента при подключении к Oracle иметь один единственный заранее установленный эээ...администратором уровень изоляции. Типа, у меня не забалуешь. Однако, тоже подход, иногда полезно.

Признаться, мне бы и в голову не пришла столь фантастическая гипотеза. Моя экспрессия означает всего лишь, что эта строка работает в строгом соответствии с ее буквальным значением, если угодно с буквальным переводом на русский язык, и поэтому меня.. крайне удивила гипотеза, высказанная в ответе, поскольку она этому значению заведомо противоречит.

ChA
*И, пожалуйста, больше так не надо, я же не тыкаю Вам в нос, что Вы не знаете, как работают установки сессии в MSSQL или какой-либо из его операторов.

Как Вам сказать... я совершенно не возражаю, если меня будут тыкать носом каждый раз, когда я позабуду нечто уже сказанное [а равно и в некоторых других случаях, например каждый раз, когда я скажу бред]. Как, скажем, недавно, когда я не обратил должного внимания на письмо Merle.
29 сен 06, 22:39    [3205455]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
andrey_anonymous
А можете показать по dml-операции между set transaction?
Это устроит
BEGIN TRAN -- По умолчанию TIL = RC
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM sysobjects WHERE id = 1
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM syscolumns WHERE id = 1
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
SELECT TOP 1 * FROM syscomments
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
SELECT * FROM syscolumns WHERE id = 2
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM sysobjects WHERE id = 2
COMMIT
Разница, как говорилось выше, только в длительности и диапазоне блокировок при чтении.
При RU - блокировки не накладываются вовсе, читать можно практически все.
При RC - накладываются только на момент чтения данных. Как упоминалось ранее, в некоторых случаях сервер может этого и не делать.
При RR - до конца текущей транзакции.
При RS - до конца текущей транзакции + охватывается дополнительный диапазон, чтобы избежать появление феноменов вставки. Может произойти эскалация вплоть до блокировки таблиц.
softwarer
Признаться, мне бы и в голову не пришла столь фантастическая гипотеза.
Наверное потому, что фактически Вы работаете только с Oracle. Мне это показалось лишь командой изменения текущей установки одного из параметров сессии. Т.е., если мне бы понадобилось изменить ее значение, то вызывал бы ее из клиента, установив другое значение TIL для моей текущей сессии, фактически, как аналог SET TRANSACTION ISOLATION LEVEL в MSSQL. Из русского буквального перевода совсем не следует ее глобальность и невозможность изменения для всех подключаемых клиентов, IMHO.
29 сен 06, 23:43    [3205759]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
Oracle. Мне это показалось лишь командой изменения текущей установки одного из параметров сессии.

Вот теперь верно. И какое отношение к "текущей установке одного из параметров сессии" - подчеркну, моей сессии - имеют

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


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

ChA
фактически, как аналог SET TRANSACTION ISOLATION LEVEL в MSSQL.

Я подозреваю, что "аналог SET TRANSACTION ISOLATION LEVEL в MSSQL" в случае Oracle называется SET TRANSACTION ISOLATION LEVEL. Хотя лень проверять.

ChA
Из русского буквального перевода совсем не следует ее глобальность и невозможность изменения для всех подключаемых клиентов, IMHO.

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

Откуда: Москва
Сообщений: 11377
softwarer
И какое отношение к "текущей установке одного из параметров сессии" - подчеркну, моей сессии - имеют

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


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

Сдается мне, мы просто друг друга не понимаем. Отсюда
softwarer
либо например триггер на logon сделает ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE, мне будет решительно наплевать, что там установил или не установил клиент.
я делаю вывод, что после того, как любой клиент подключился к Oracle, ему тут же устанавливается определенный уровень TIL. Ведь это же триггер на logon, где можно, насколько понимаю, прописать некий контекст, в котором должен, по крайней мере - начать, работать клиент сразу после подключения. Но ведь БД может быть не одна, и даже на одной БД для работы разных клиентов(программ, а не пользователей(!)) может понадобиться различный TIL. Как же быть в этом случае ? Вы говорите "мне будет решительно наплевать, что там установил или не установил клиент", откуда я делаю вывод, что команда ALTER SESSION SET ISOLATION_LEVEL препятствует изменению TIL. И тогда я Вас переспрашиваю
ChA
Клиент, ничтожно сумняшеся, не сможет поставить другой уровень изоляции ?
. На что Вы мне отвечаете вопросом
softwarer
Как именно он сможет это сделать?
и, более того, предлагаете внимательно прочитать и перевести буквально текст команды. После чего мне не остается ничего другого, как считать, что после задания в триггере на логон командой ALTER SESSION SET ISOLATION_LEVEL клиент не может поменять уровень изоляции своей сессии. И что же дальше ? Я пытаюсь пояснить
ChA
Из русского буквального перевода совсем не следует ее глобальность и невозможность изменения для всех подключаемых клиентов, IMHO.
На что Вы отвечаете
softwarer
Мало того, если бы следовало, Ваш пассаж насчет разных задач и требований был бы обоснован. Но поскольку не следует и совершенно справедливо не следует....
И вот тут я совсем перестаю Вас понимать.
Если TIL все-таки можно изменить после установки его в триггере логона командой ALTER SESSION SET ISOLATION_LEVEL, то значит клиент может выполнить какую либо из процедур БД не под тем TIL, который предполагал разработчик БД, а, соответственно, вольно или невольно нарушить логическую целостность БД, по причине того, например, что процедура прочитала незакоммиченные данные, в соответствии с текущим TIL, установленным им, - RU. Ведь проверку текущего TIL в процедуре Вы считаете хлопотным аналогом "гланды бормашиной". Установка TIL в процедуре тоже "идеологический бред". Как же тогда быть ? Можно конечно предположить, что в Oracle можно каким-то третьим способом зафиксировать TIL для конкретной процедуры, и все хлопоты побоку, но мне, увы, об этом неизвестно, но понять хотелось бы, как решаются подобные проблемы.
*Собственно, с этих "гланд" все и началось.
30 сен 06, 00:54    [3205949]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
DimaR
Member

Откуда:
Сообщений: 1570
например, что процедура [b]прочитала незакоммиченные данные[/b] соответствии с текущим TIL

В Oracle такого небывает

По умолчанию все сессии работаю в Read Commited (так сказать минимальный).

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

Если же она ожидает работать в Read Commited и сама себе его установит, то опять же значит так и надо.
30 сен 06, 09:53    [3206220]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
DimaR
например, что процедура [b]прочитала незакоммиченные данные[/b] соответствии с текущим TIL

В Oracle такого небывает
Я рад за Oracle, но это был пример. Не знаю я, что там бывает в Oracle, а чего нет. Хорошо, серверная процедура написана подразумевая RS, чтобы избегать фантомов вставки. А клиент установил себе RC и в какой-то момент запускает упомянутую процедуру. Она благополучно "хавает" фантом и опять же нарушает логическую целостность. Или такого тоже быть не может ?
И еще. TIL = RU в Oracle, насколько понимаю, вообще не бывает, краем же уха мелькало, что и с RS у него какие-то проблемы. Можно ли понять так, что фактически у него нет разных TIL, или их, по сути, не больше 2х: RC и RR, который несильно отличается от RC ? Только не воспринимайте это как наезд на Oracle, ради Бога. Всего лишь хочется понять, как он справляется с несогласованностью ожидаемого и реального TIL.
DimaR
Если же она ожидает работать в Read Commited и сама себе его установит, то опять же значит так и надо.
Кому надо ? Значит ли это, что Oracle не гарантирует автоматически корректность работы при разногласии TIL подразумеваемой автором серверной процедуры и ее работы в контексте сессии клиентской части ? И она целиком зависит от согласованности действий разработчика БД и программиста клиентской части. Т.е., если автор серверной процедуры не предусмотрел никакого способа по проверке текущего TIL и/или явной установки TIL, то клиент может невзначай(ли) нарушить упомянутую целостность БД, вызвав ее при другом значении TIL.
30 сен 06, 14:52    [3206534]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ChA
Хорошо, тогда ответьте на такой вопрос - почему в стандарте ANSI есть оператор SET TRANSACTION, если его применение идеологически неверно ? Кроме того, по стандартам ANSI рекомендуется вообще не допускать возможностей работы вне транзакций. В Informix, если правильно помню, он так и назывался ANSI mode, у MSSQL - implicit. Для такого режима вообще нет понятия начала транзакции, так как вы всегда работаете в транзакции. Единственное, что можно, это делать COMMIT или ROLLBACK, после которой автоматически начинается следующая транзакция. В этом режиме тоже будем запрещать менять уровень транзакций ?
И, пожалуйста, больше не надо лозунгов про M$, не на демонстрации. На уровне "маздай" общаться в дальнейшем не намерен.


В Oracle SET TRANSACTION разрешается выполнять только непосредственно после завершения очередной транзакции и перед началом выполнения каких либо действий в новой транзакции. Если интересно, в теме Oracle есть продолжительное обсуждение на тему "Когда начинается транзакция", можно поискать. Кстати, не следует это путать с autocommit о котором вы говорите, когда каждый оператор выполняется в ОТДЕЛЬНОЙ транзакции, в Oracle именно потому и нет команды начала транзакции, что он всегда выполняет действия в транзакции, без всяких autocommit-ов (может себе это позволить).

P.S. Не хочешь лющаться - не общайся, кто же тебя заставит ???
2 окт 06, 08:46    [3208570]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ChA
Вас ведь не смущают автономные транзакции ?


Не смущают. А вот возможность изменения уровня изоляции в ходе транзакции, смущает ОЧЕНЬ
2 окт 06, 08:49    [3208575]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
Сдается мне, мы просто друг друга не понимаем.

Видимо. Давайте смотреть.

ChA
Отсюда ..... я делаю вывод, что после того, как любой клиент подключился к Oracle, ему тут же устанавливается определенный уровень TIL.

В целом верно.

ChA
Но ведь БД может быть не одна, и даже на одной БД для работы разных клиентов(программ, а не пользователей(!)) может понадобиться различный TIL.
Как же быть в этом случае ?

А что мешает устанавливать каждой программе и/или каждому пользователю нужный TIL?

Я не понимаю, почему Вы говорите об установках сессии так, словно они едины для всех, кто работает с БД.

Также я не понимаю, почему по Вашим словам внутри сессии борятся разные клиенты. Такое впечатление, что моя программа установила нужный уровень изоляции, а все остальные лезут своими грязными руками в сессию моей программы и мешают ей работать. Вот я и спросил среди прочего - как они могли бы это сделать, даже имея такое желание?

Давайте пройдемся по пунктам с моей стороны. Прежде всего, Вы говорите:

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

Я в этот момент не совсем понимаю, что Вы имеете в виду под клиентом - то ли разные программы, подключающиеся к одной базе, то ли разные базы (например, разных пользователей программы, один из которых выполнил рекомендуемую настройку базы, а другой для своей БД проигнорировал рекомендацию). Но в обоих случаях действует один и тот же ответ:

Если моя программа .. сделает ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE, мне будет решительно наплевать, что там установил или не установил клиент.

То есть: моя программа может настроить себе личный контекст работы, в который никто кроме нее, не залезет и который никому снаружи не помешает. Она работает как ей нужно, и на внешние настройки ей наплевать точно так же, как всем остальным наплевать на настройки ее сессии.

Как Вы сказали чуть позже, Вы поняли, что это именно настройки сессии. Я на это надеялся. Но тогда я совершенно не понимаю ответа:

И что ? Клиент, ничтожно сумняшеся, не сможет поставить другой уровень изоляции ? Он может совершенно не предполагать, что некий триггер на logon уже его устанавил. Более того, по задаче ему нужен другой уровень изоляции. К одной и той же БД может быть подключено несколько разных клиентов, написанных разными командами и решающими совершенно разные подзадачи, и у каждого из них могут быть свои требования.

Вот тут я просто не понимаю, что происходит. Мы говорим о настройках сессии, но откуда-то появляются "несколько разных клиентов", которые почему-то мешают уровню изоляции моей сессии, в моей сессии появляется какой-то другой клиент, который судя по всему написан не мной.... бред какой-то. Учитывая, что Вы похоже подразумеваете некие единые для всего сервера настройки TIL, я подчеркиваю, что речь идет о настройках сессии, не более того.

- RU. Ведь проверку текущего TIL в процедуре Вы считаете хлопотным аналогом "гланды бормашиной".

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

Установка TIL в процедуре тоже "идеологический бред". Как же тогда быть ?

Не "установка TIL в процедуре", а "смена TIL по ходу транзакции". Если процедура выполняет транзакцию целиком, например для отчета - устанавливает RR, выполняет требуемые запросы, завершает транзакцию, возвращает результаты клиенту для отображения - не вижу ничего страшного.

Я уже сказал, как. Я предпочитаю работать так, чтобы в системе было малое количество не-RC транзакций и соответственно хранимок, требующих более чем RC. Также я избегаю хранимок, явно управляющих транзакциями (исключая savepoint-ы); это облегчает их повторное использование.
2 окт 06, 13:26    [3210112]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
softwarer
Как Вы сказали чуть позже, Вы поняли, что это именно настройки сессии. Я на это надеялся. Но тогда я совершенно не понимаю ответа:
И что ? Клиент, ничтожно сумняшеся, не сможет поставить другой уровень изоляции ? Он может совершенно не предполагать, что некий триггер на logon уже его устанавил. Более того, по задаче ему нужен другой уровень изоляции. К одной и той же БД может быть подключено несколько разных клиентов, написанных разными командами и решающими совершенно разные подзадачи, и у каждого из них могут быть свои требования.
Вот тут я просто не понимаю, что происходит.

Александр, тут как раз все понятно.
Cha рассматривает сценарий, когда триггер on_logon устанавливает serializable, но приложение имеет собственное мнение по данному вопросу.
Вполне адекватный довод в контексте дискуссии о практичности изменения TIL непосредственно в ХП.
Другой вопрос, что системы слишком разные чтобы проводить подобные параллели - MSSQL не имеет аналога "ораклевого" RC, что и вынуждает менять TIL, oracle же не позволяет менять уровень изоляции посреди транзакции, что заставляет избегать управления уровнем изоляции внутри хранимых процедур.
Я лично не готов сказать какая из систем более "правильна" в данном вопросе, поскольку oracle слишком привычен и мнение будет предвзятым :)
2 окт 06, 14:15    [3210514]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
andrey_anonymous
Александр, тут как раз все понятно.
Cha рассматривает сценарий, когда триггер on_logon устанавливает serializable, но приложение имеет собственное мнение по данному вопросу.

Андрей, а кто пишет этот триггер? Каким образом мое приложение и мой триггер могут иметь различные собственные мнения на тему желаемого уровня изоляции? Это что, такое проявление шизофрении?

С другой стороны, если есть мое приложение, а кто-то другой, например администратор клиента, написал триггер на логон - именно этот кто-то и отвечает за последствия такого решения. Но именно поэтому я в первую очередь упомянул прямую установку параметра из программы, а триггер на логон - уже как возможную альтернативу для каких-то специфических ситуаций.
2 окт 06, 14:31    [3210646]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
4321ё
Guest
softwarer
если есть мое приложение, а кто-то другой, например администратор клиента, написал триггер на логон - именно этот кто-то и отвечает за последствия такого решения.

позвольте темному пояснить:

имхо очевидно, штаа ChA обсуждает случай, кады некая хапа делает именно то, что заявлено проектировщиком хапы, _независимо_ от того, кито писал (и буит пИсать) килиентаф. (что предпочтительно - "база и ее объекты поведенчески не зависят от настроения клиентов - и это праильно"). вы же - только соглассованную работу клиентаф и хапоф. вот сопсно и все. и я не думаю, что вы этого не поняли постов эдак эн тому взад. а домыслы про посторонних, лезущих хрясными ногхами в вашу рОдную зессию - вне фсякого контекста беседы. тут, как грицца ... нет злофф
2 окт 06, 15:52    [3211211]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
ChA
Значит ли это, что Oracle не гарантирует автоматически корректность работы при разногласии TIL подразумеваемой автором серверной процедуры и ее работы в контексте сессии клиентской части ? И она целиком зависит от согласованности действий разработчика БД и программиста клиентской части. Т.е., если автор серверной процедуры не предусмотрел никакого способа по проверке текущего TIL и/или явной установки TIL, то клиент может невзначай(ли) нарушить упомянутую целостность БД, вызвав ее при другом значении TIL.
На этот вопрос кто-нибудь из знатоков Oracle способен внятно ответить или нет ?
Если вопрос поставлен некорректно, то просьба пояснить - почему.

P.S. В принципе, судя по некоторым оговоркам softwarer-а, подозреваю, что корректность таки не гарантируется, если нет согласованности действий разработчиков серверной и клиентской частей, но хотелось бы явного подтверждения.
2 окт 06, 16:36    [3211505]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
На этот вопрос кто-нибудь из знатоков Oracle способен внятно ответить или нет ? Если вопрос поставлен некорректно, то просьба пояснить - почему.

Хм. Наверное, способен любой, хотя вопрос имхо бессмысленный.

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

Я не понимаю, о чем Вы говорите, говоря о согласованности действий разработчика сервера и разработчика клиента. Если есть некоторое разделение полномочий, значит есть определенное API, которым пользуется разработчик клиента. Это API - единственный способ его общения с БД, и установка нужного контекста - задача именно этого API. Вся согласованность заключается в том, что клиент не лезет в базу мимо оговоренного интерфейса взаимодействия, что уже давно стало скорее элементом культуры, нежели требованием технологии.

Может быть, в этом и заключается причина нашего непонимания.

ChA
P.S. В принципе, судя по некоторым оговоркам softwarer-а, подозреваю, что корректность таки не гарантируется, если нет согласованности действий разработчиков серверной и клиентской частей, но хотелось бы явного подтверждения.

Хм. Расскажите тогда уж, гарантируется ли то же самое в других реализациях и как именно.
2 окт 06, 17:08    [3211724]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
ChA
ChA
Значит ли это, что Oracle не гарантирует автоматически
На этот вопрос кто-нибудь из знатоков Oracle способен внятно ответить или нет ?

Сервер может Автоматически Гарантировать только то, что соответствующим образом задекларировано.
Oracle PL/SQL не предусматривает каких-либо способов декларации TIL => запуск процедуры в среде с иным значением TIL может нарушить логику работы процедуры.
ЗЫ: мне интересно, к каким именно выводам это сообщение приведет уважаемого оппонента :)
2 окт 06, 18:53    [3212334]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
softwarer
Если хранимка, требующая для своей работы некоторого определенного контекста, вызвана в условиях, нарушающих этот контекст, и при этом не пытается ни установить нужный контекст, ни проверить его корректность, то результаты ее работы скорее всего непредсказуемы.
Ну, наконец-то. TIL в процедуре не проверяем, не устанавливаем, получаем ошибку. Все. Продолжать не надо.
*Именно это я и пытался выяснить. Одного не могу понять, почему смысл вопроса похоже был понятен почти всем, кроме Вас.
softwarer
Я не понимаю, о чем Вы говорите, говоря о согласованности действий разработчика сервера и разработчика клиента. Если есть некоторое разделение полномочий, значит есть определенное API, которым пользуется разработчик клиента. Это API - единственный способ его общения с БД, и установка нужного контекста - задача именно этого API.
Искренне рад за Вас, что живете в идеальном мире и никогда не сталкивались с тем, что имея API, тем не менее, сплошь и рядом использующие его разрабочики делают ошибки при его использовании, не говоря уж о том, что и разработчики API далеко не безгрешны.
*Тему про то, что надо гнать таких разработчиков, предлагаю не развивать. Я тоже хотел бы жить в идеальном мире.

softwarer
Расскажите тогда уж, гарантируется ли то же самое в других реализациях и как именно.
Про всех не знаю, в MSSQL точно не гарантируется. Но есть возможность минимизировать влияние подобных ошибок, в частности, проверкой и/или изменением TIL. Теоретически, да и практически, наверняка это может привести к ошибках в некоторых ситуациях. Но тем не менее эта же возможность может дать в определенных ситуациях прирост производительности и/или гарантию целостности, если, разумеется, грамотно ею пользоваться, просчитывая последствия.
Практический пример: если известно, что данный отчет требует только TIL=RR, то в процедуре, реализующей такой отчет, несложно именно это и указать. И мне все равно, что клиентской части для большинства операций требуется всего лишь RC. Запуская мою процедуру, программист КЧ в любом случае получит вполне консистентный отчет, даже не задумываясь, а какой же он должен был проставить TIL для этого. Разумеется, можно его заставить в самом начале сессии установить RR и работать только под ним, но на большинстве операций это будет более чем излишне и даже вредно. В частности, может просесть проиводительность в многопользовательской среде, так как появится больше конфликтов на блокировках.
*В некотором смысле, мне кажется это более грамотный подход к API, чем меньше разработчику КЧ нужно знать о сервере, TIL и прочей лабуде, тем лучше. IMHO.
andrey_anonymous
мне интересно, к каким именно выводам это сообщение приведет
Ровно к этим
andrey_anonymous
запуск процедуры в среде с иным значением TIL может нарушить логику работы процедуры


P.S. В принципе, на этом предлагается закончить мой офтоп.
2 окт 06, 19:38    [3212462]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
2 ChA
Вы упустили один важный момент - в оракле TIL можно выставить только завершив предыдущую транзакцию и, соотв. автоматически начав новую.
Для вашего примера с ХП, эта процедура первой командой говорит COMMIT, потом SET TRANSACTION <то, что нам надо>. Последней командой тоже будет COMMIT, чтобы сбросить TIL в дефолтный. Этим и обеспечится независимость серверного кода от текущих настроек транзакции сессии вызывающего клиента.

--
Антон
Per rectum ad astrum
2 окт 06, 20:14    [3212518]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11377
Anton Demidov
2 ChA
Вы упустили один важный момент - в оракле TIL можно выставить только завершив предыдущую транзакцию и, соотв. автоматически начав новую.
Я не упустил, я этого даже не знал. Поэтому и спрашивал - как ? Теперь знаю, собственно об этом уже несколько ранее сказал Gluk (Kazan).
Anton Demidov
Для вашего примера с ХП, эта процедура первой командой говорит COMMIT, потом SET TRANSACTION <то, что нам надо>. Последней командой тоже будет COMMIT, чтобы сбросить TIL в дефолтный. Этим и обеспечится независимость серверного кода от текущих настроек транзакции сессии вызывающего клиента.
Но при этом, насколько понимаю, будет разорвана транзакция. Вообще, как обходить - это уже совсем другой вопрос, ответ на него сразу проистекает из Вашего предыдущего абзаца, но ранее мне на него уже четко ответили, что не царское это дело. Не соблюл, сам виноват, получи неявную ошибку. Это ни хорошо, это ни плохо - это так.
2 окт 06, 21:07    [3212612]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19913
ChA
Это ни хорошо, это ни плохо - это так.

Вообще разница по отношению к MSSQL есть.
"Оракловый" RC - штука настолько удобная и сбалансированная, что потребность в serializable - скорее экзотика.
Если я правильно понял, то последовательность

select from t1...
select from t2...
select from t3...

в MSSQL будет выглядеть примерно как

set transaction isolation level repeatable_read;
select from t1...
set transaction isolation level read_commited;
set transaction isolation level repeatable_read;
select from t2...
set transaction isolation level read_commited;
set transaction isolation level repeatable_read;
select from t3...
set transaction isolation level read_commited;

Ну и плюс блокировки...
2 окт 06, 21:18    [3212631]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ChA
*Именно это я и пытался выяснить. Одного не могу понять, почему смысл вопроса похоже был понятен почти всем, кроме Вас.

Я не понимаю, почему Вы ожидали от меня ответа на вопрос, адресованный не мне. Собственно, я не читал Вашу беседу с Димой, и увидел его только в Вашей же цитате.

Также меня удивляет, что Вы задали вопрос, ответ на который я практически дал еще пару страниц назад, и оказывается просили на него ответить.

ChA
Искренне рад за Вас, что живете в идеальном мире

Хм. До сих пор я считал, что сталкиваюсь с кучей недоработок в технологии разработки. Но за последние несколько дней уже в третий раз слышу, что ситуация, которая с моей точки зрения кишит недостатками, с точки зрения MSSQL-разработчиков является недостижимым идеалом. Забавно...

ChA
и никогда не сталкивались с тем, что имея API, тем не менее, сплошь и рядом использующие его разрабочики делают ошибки при его использовании, не говоря уж о том, что и разработчики API далеко не безгрешны.

Прежде всего, я прошу Вас не уводить разговор в сторону, и таки объяснить, что за взаимодействие Вы подразумеваете и какое место оно занимает в технологии разработки. Просто нарисовать картину: есть такие-то люди, у них такие-то обязанности, они делают то-то, и если не договорятся вот здесь вот об этом, будет плохо.

Далее, Вы в очередной раз рисуете некую странную картину. Раньше у нас была разделяемая сессия, теперь оказывается в результате "ошибки в использовании API" программист клиента по собственному разумению устанавливает уровень изоляции. Хотелось бы получить более подробное описание ситуации, как Вы ее видите.

Наконец, отмечу, что если мой программист начхает на оговоренный интерфейс и выполнит что-то, в том числе ALTER SESSION, в обход специфицированного взаимодействия - я, видимо, буду шокирован. До сих пор я так был шокирован единственный раз в жизни; отмечу, что те двое сотрудников - единственные до сих пор, кого я уволил. И надеюсь больше с таким не встретиться. Если хотите, считайте это идеальным миром.

ChA
Но тем не менее эта же возможность может дать в определенных ситуациях прирост производительности и/или гарантию целостности, если, разумеется, грамотно ею пользоваться, просчитывая последствия.

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

В целом, пожалуй, я бы отметил две вещи. Первая: как только мы говорим, что нужно грамотно пользоваться и просчитывать последствия, мы тем самым поднимаем требования к разработчику; об упрощении разработки речи не идет (согласен, вполне может идти об эффективности). Вторая: если вспомнить, что стартовали мы с консистентного чтения, то в целом я весьма рад, что его существование в Oracle избавляет меня от просчета подобных ситуаций. Что касается цены вопроса... в принципе, конечно, консистентность стоит определенных ресурсов, требуя дополнительных чтений. Я замерял производительность запросов в зависимости от количества старых данных, которые нужно поднять, и пришел к выводу, что в практически встречающихся ситуациях соответствующие потери пренебрежимо малы, меньше одного процента; чтобы получить серьезную разницу, надо специально моделировать ситуацию.

ChA
Запуская мою процедуру, программист КЧ в любом случае получит вполне консистентный отчет, даже не задумываясь, а какой же он должен был проставить TIL для этого.

Простите, я снова не понимаю технологии, которую Вы подразумеваете. Программист клиентской части никогда-никогда-никогда не устанавливает TIL, если, конечно, мы говорим о процессе разработки с четко очерченными полномочиями (то есть о процессе, где есть смысл говорить о "программисте КЧ"). Вместо этого программист КЧ вызывает специфицированные для него методы интерфейса; для простоты считайте, что это ХП. Программист серверной части реализует эти методы, в том числе распихивает по ним установку уровня изоляции, если это нужно. Скажем, если Вы будете программистом КЧ, получите от меня задание что-нибудь вроде "сразу после коннекта к БД вызвать ХП Init с такими-то параметрами". Эта процедура сделает много всего, скажем даст сессии полагающиеся роли, настроит row-level security, инициализирует серверные переменные и прочий контекст, в том числе, если нужно, выполнит ALTER SESSION SET ISOLATION_LEVEL. Вы как программист КЧ об этом думать не будете, а знать - только если полюбопытствуете.

ChA
*В некотором смысле, мне кажется это более грамотный подход к API, чем меньше разработчику КЧ нужно знать о сервере, TIL и прочей лабуде, тем лучше. IMHO.

Возможно, это более грамотный подход, но я не понял, с какой хренью Вы его сравниваете и откуда Вы ее откопали.
2 окт 06, 22:59    [3212771]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить