|
|
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous"Оракловый" RC - штука настолько удобная и сбалансированная, что потребность в serializable - скорее экзотика. Здесь я уже высказал такую гипотезу ChATIL = RU в Oracle, насколько понимаю, вообще не бывает, краем же уха мелькало, что и с RS у него какие-то проблемы. Можно ли понять так, что фактически у него нет разных TIL, или их, по сути, не больше 2х: RC и RR, который несильно отличается от RC ? Вы ее сейчас фактически подтвердили. andrey_anonymousЕсли я правильно понял, то последовательность Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plaintext 1. 2. 3. 4. softwarerДалее, Вы в очередной раз рисуете некую странную картину. Раньше у нас была разделяемая сессия, теперь оказывается в результате "ошибки в использовании API" программист клиента по собственному разумению устанавливает уровень изоляции. Хотелось бы получить более подробное описание ситуации, как Вы ее видите.Вы просто смотрите странным взглядом. Это у Вас откуда-то появилась "разделяемая" сессия, которая появилась неизвестно каким боком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 01:31 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Случайно сохранил. Впрочем, это уже неважно. Господин softwarer, не вижу смысла в продолжении нашей беседы на эту тему, разрешите откланяться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 01:38 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChA andrey_anonymous"Оракловый" RC - штука настолько удобная и сбалансированная, что потребность в serializable - скорее экзотика. Здесь я уже высказал такую гипотезу Простите, но по ссылке Вы высказывали какие-то совсем другие гипотезы :) ChA. andrey_anonymousЕсли я правильно понял, то последовательность Код: plaintext 1. 2. 3. Почему ? Если для 3 идущих подряд селектов мне нужен RR Нет. Мне нужен RC, но каждый запрос должен вернуть консистентный набор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 02:09 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
ChAСлучайно сохранил. Впрочем, это уже неважно. Господин softwarer, не вижу смысла в продолжении нашей беседы на эту тему, разрешите откланяться. Кланяйтесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 03:47 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousПростите, но по ссылке Вы высказывали какие-то совсем другие гипотезыОК, другие. Можете их подтвердить или опровергнуть ? Впрочем, не надо. Мне будет проще прочитать в документации по Oracle, потому что устал от версий, что я спросил или что имел в виду. Возможно, у меня дар выражаться непонятно. andrey_anonymousМне нужен RC, но каждый запрос должен вернуть консистентный набор.Если Вам нужен консистентный набор, то, по стандарту и в MSSQL, нужно устанавливать TIL не ниже RR. Об этом уже говорилось, кажется, на 8 странице. Если между выполнением селектов по каким-то причинам надо быть в RC, то Ваш первый скрипт был верным. Но это имеет смысл, только если между селектами, а точнее - между изменениями TIL, выполняется еще какой-либо осмысленный код, которому для корректного выполнения достаточно RC. В противном случае, смысл перехода в RC, чтобы следующей выполняемой строкой снова перейти в RR лично для меня непонятен, хотя такой код вполне возможен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 04:00 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousНет. Мне нужен RC, но каждый запрос должен вернуть консистентный набор. Насколько я понимаю реализацию MSSQL, в приведенном ChA коде Вы получите именно то, что ожидаете. Подозреваю, здесь снова различие в деталях реализации одинаково называемых TIL. Вы привыкли понимать RR как согласованность всех наборов данных в транзакции; как и в случае RC это более сильное требование, чем в RR в MSSQL-реализации. В последнем случае, как я понимаю, на прочитанные записи накладывается блокировка до конца транзакции, что обеспечивает неизменность данных до конца транзакции (и следовательно их повторное считывание, причем не только RR-транзакцией, а и всеми остальными тоже). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 11:18 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
С большим интересом прочитал всё обсуждение. В процессе чтения меня постоянно не покидало ощущение абсолютной бессмысленности топика и полного непонимания оппонентами друг друга. А зачастую и непонимания предмета обсуждения. Примеры. ASCRUS называет фантомами то, что ими никоем образом не является. И все согласны... ChA говорит что в Oracle RC фактически эквивалентен RR. И опять все согласны... Ещё кто-то говорит, что в Oracle нет serializable, потому что там фантомы. И снова всё согласны... Господа, но ведь всё это неправда. RC в Oracle - нормальный RC, соответствующий требованиям согласованности. Как у нормального версионника это "честная" согласованность. Никаким RR тут и не пахнет. Это честный RC, в отличие от того же MSSQL. И других блокировочных серверов в которых понятие согласованности весьма относительно. И это их "плата". В настоящем версионнике, как и в Oracle, нет и не может быть уровня изоляции repeatable read в принципе. Он там просто не получается! За RC сразу следует serializable. Естественно никаких фантомов в serializable нет и быть не может, по определению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 15:25 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
pavelvpASCRUS называет фантомами то, что ими никоем образом не является. И все согласны... ChA говорит что в Oracle RC фактически эквивалентен RR. И опять все согласны... Ещё кто-то говорит, что в Oracle нет serializable, потому что там фантомы. И снова всё согласны... Естественно никаких фантомов в serializable нет и быть не может, по определению. Не то чтобы согласны, но не хотят разводить флейм :) Однако serializable в Oracle действительно не соответствует последнему стандарту (чуть упростили определение). Действительно можно построить такую схему взаимодействия параллельных пишущих транзакций, в результате которой база данных перейдет в состояние, которое невозможно получить при последовательном их выполнении. Правда, бизнес-смысл подобной конструкции несколько туманен, но факт есть факт - постороить можно :) К читающим транзакциям это действительно не относится, но опять-таки тема слишком флеймоопасна :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 15:43 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousДействительно можно построить такую схему взаимодействия параллельных пишущих транзакций, в результате которой база данных перейдет в состояние, которое невозможно получить при последовательном их выполнении. Не ради флейма, но всё же можно примерчик такой схемы взаимодействия? Для меня непонятно, что значит "схема взаимодействия параллельных пишущих транзакций"... Что это за такое взаимодействие параллельных транзакций? Как-то нехорошо звучит эта фраза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 19:32 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
pavelvp andrey_anonymous Не ради флейма, но всё же можно примерчик такой схемы взаимодействия? Проще простого: Код: plaintext 1. 2. Сессия1: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Сессия2: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Снова сессия1: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Попробуйте получить аналогичный результат, выполняя транзакции последовательно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 19:47 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Андрей, что-то я ваш пример не понял. Нормальное поведение, причём не зависит от установок set transaction isolation level - проверил на 9.2.0.8 Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 20:59 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Anton DemidovАндрей, что-то я ваш пример не понял. Нормальное поведение С какой точки зрения нормальное? С точки зрения определения сериализуемости - определенно нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 21:02 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Anton DemidovВ доке говорится про модификацию, у нас - вставка. Во-первых, как мне кажется, Вы привели не совсем удачный пример. "modify table" - это вовсе не только update. Лучший линк - например, http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#sthref1981 Обратите внимание на Serializable isolation permits concurrent transactions to make only those database changes they could have made if the transactions had been scheduled to run one after another. - это фактически цитирование стандартного определения, и пример Андрея показывает, что все не так просто, а дальше там написано следующее: Although Oracle serializable mode is compatible with SQL92 and offers many benefits compared with read-locking implementations, it does not provide semantics identical to such systems. Application designers must take into account the fact that reads in Oracle do not block writes as they do in other systems. Transactions that check for database consistency at the application level can require coding techniques such as the use of SELECT FOR UPDATE. This issue should be considered when applications using serializable mode are ported to Oracle from other environments. Фактически Oracle подразумевает под "сериализацией" "сериализацию update/delete". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 22:08 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 23:26 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Anton DemidovЧто неправильно? Антон, попробуйте: 1) взять себя в руки 2) прочитать определение serializable в последней версии стандарта 3) получить аналогичный результат, выполняя, в соответствии с определением, данные транзакции последовательно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2006, 23:35 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Взял себя в руки, напряг гугл и нашел это . Наш любимый Том Кайт развенчивает очередной миф на нашем же примере. Вот сам текст стандарта. В комментариях (конец стр. 68, начало стр. 69) отчетливо прописано, что : SQL92Together with serializable execution, this implies that all read opera- tions are repeatable within an SQL-transaction at isolation level SERIALIZABLE, except for: 1) the effects of changes to SQL-data or schemas and its contents made explicitly by the SQL-transaction itself, 2) the effects of differences in parameter values supplied to pro- cedures, and 3) the effects of references to time-varying system variables such as CURRENT_DATE and CURRENT_USER. Как видите, первый пункт у нас не выполняется. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 00:42 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Anton DemidovВзял себя в руки [quot SQL92] Код: plaintext Нет, Антон, не взяли. SQL92 - это далеко не последняя версия стандарта. Ищите лучше :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 00:57 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Anton DemidovКак видите, первый пункт у нас не выполняется. Кстати, дело совсем не "в первом пункте" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 00:59 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
2Anton Demidov вы не внимательно прочли даже этот топик. ситуация такая - есть стандарт 92 года, в нем serializable дефинируется через феномены, оракловый serializable полностью избавляет от всех феноменов из стандарта, поэтому полностью отвечает требованиям стандарта 92. однако позже (в 98-ом наверно) до них дошло, что у версионников вообще другие уровни и ввели новый уровень snapshot, а serializable в новом стандарте требует эфекта последовательного исполнения транзакций. наверно оракл мог бы ввести блокировки предикатов и новый уровень serializable98, чтоб удолетворить новое требование, но похоже это нафиг кому нужно и поэтому теперь вроде как получается, что serializable у оракла не честный ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 01:05 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Андрей, я так понял, что "стандарт" неведомого нам года (вам, похоже тоже, т.к. иначе давно бы указали ссылку) требует блокировки чтения во второй сессии вашего примера. andrey_anonymous Сессия2: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Угадал? Может не будете больше намёками говорить - вроде здесь все свои? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 01:57 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
в InterBase/Firebird уровень изолированности SERIALIZABLE эмулируется при помощи явной блокировки таблиц. При старте транзакции есть параметр consistency, это то же самое что snapshot, но блокировки на таблицы накладываются не shared, а exclusive. и можно наложить блокировки по чтению и по записи для конкретных таблиц (перечислив при старте транзакции). А также поставить режим wait. В результате транзакция при старте повиснет на блокировке таблицы, если такая обнаружится, а при "отвисании" заблокирует нужные таблицы напрочь, до своего завершения. Если же wait не ставить, то такая транзакция при обнаружении несовместимых конкурирующих транзакций будет обламываться сразу при старте. таким образом доступ к таблицам можно обеспечить "последовательным" исполнением транзакций. Однако понятно, что в конкурентной среде при большом числе активных транзакций у таких транзакций-"блокировщиков" мало шансов стартовать (в смысле дождаться освобождения изменения нужных таблиц конкурирующими транзакциями). В частности, этот режим можно использовать для редких операций, например монопольного редактирования справочников. Если редактирование справочника организовать в такой транзакции, то оно всегда будет монопольным. По чтению конкурирующие транзакции в этом случае блокировать не обязательно (как этого требует стандарт). www.ibase.ru/devinfo/ibtrans.htm , см. set transaction ... reserving. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 02:53 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Yo.!!вы не внимательно прочли даже этот топик. ситуация такая - есть стандарт 92 года, ...... однако позже (в 98-ом наверно) до них дошло, что у версионников вообще другие уровни ... Я бы чуть иначе расставил акценты. Понятие serializable существует давно, придумано задолго до 92-го года, со вполне четким определением. Когда творили стандарт'92, как и в других подобных случаях, пошли на очень неудачные компромиссы, основной целью которых было хоть чучелом, хоть тушкой, но впихнуть существующие реализации в этот стандарт. В том числе поэтому стандарт до сих пор, включая SQL2003, серьезного практического смысла не имеет, хотя надо сказать, он намного лучше SQL92. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 08:17 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Yo.!!наверно оракл мог бы ввести блокировки предикатовА у Oracle нет блокировки предикатов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 10:48 |
|
||
|
Версионники и блокировочники
|
|||
|---|---|---|---|
|
#18+
Yo.!!2Anton Demidov вы не внимательно прочли даже этот топик. ситуация такая - есть стандарт 92 года, в нем serializable дефинируется через феномены, оракловый serializable полностью избавляет от всех феноменов из стандарта, поэтому полностью отвечает требованиям стандарта 92 . Позвольне несогласиться. Приведенный Андреем пример полностью противоречит следующим строчкам стандарта: SQL92 The execution of concurrent SQL-transactions at isolation level SERIALIZABLE is guaranteed to be serializable. A serializable exe- cution is defined to be an execution of the operations of concur- rently executing SQL-transactions that produces the same effect as some serial execution of those same SQL-transactions. A serial exe- cution is one in which each SQL-transaction executes to completion before the next SQL-transaction begins. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2006, 10:49 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=34030753&tid=1553078]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 364ms |

| 0 / 0 |
