Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
hvlad Версионнику не нужно держать логические блокировки до окончания тр-ции, т.к. он версионник ;) Поэтому у него даже такого понятия нет, как блокировка записи. ... А версионник - держит блокировки ровно столько, сколько нужно для модификации страницы при создании версии записи. При обновлении миллиона записей версионник не будет держать одновременно более 1-ой блокировки страницы. Поэтому он и выигрывает при конкурентном доступе у блокировочника. Всё что я пишу о версионнике, относится к IB\FB, так что ораклистов прошу понимать меня правильно :) Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ????????????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 08:28 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
ZaxxВы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????Да. Только на время изменения. И не запись, а страницу, на которой она лежит. Это так сложно для понимания ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:25 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Всем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon Там все доходчиво изложено. Теоритически, очень не плохо, практически, поживем - увидим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:30 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
DoomaВсем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon Там все доходчиво изложено. Merle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:42 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
авторMerle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID.Я не знакомый Merle, но слышал, что этот чел общается с разработчиками из MS. Пусть Merle поправит, если что не так. И в чем в чем, а в MS ему можно доверять. А с Oracle вы и сами в состоянии сравнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 10:50 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
vadiminfoВажна для начала конкретная. А уже ее разультаты можно как-то трактовать. Мне не ясно, что дает отсутсвие read в первой транзакции. Это инсетрт, который вообще никак не пересекается с апдэйтом второй транзакции? Или что? В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации". vadiminfo Допустим это Ваш счет в банке. Вы ожидали, что там будет 10 тыс баксов, но транзакции выполнились в последовательности т2,т1. И там стало вместо этого 9 тыс. Вы по прежнему будете считать этот результат тоже правильным? Ну, тогда я не знаю. Я не ожидаю конкретного состояния счета. Я ожидаю что в рамках правил операций с моим счетом его состояние будет правильным. Если кто то удвоил состояние счета (положил 4 тысячи), а потом кто то имеющий право работать со счетом доложил еще 1 тысячу, то на счету будет 9 тысяч и это правильно (в общей сложности положено 5 тысяч). А вот если оба считали состояние счета как 4 тысячи, а второй закоммитился позже первого, то на счету будет 5 тысяч. То есть на счету было 4 тысячи, добавили туда еще 5 тысяч и в результате получилось 5 тысяч. Вот это как раз неправильно (пропали 4 тысячи рублей). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 14:32 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
hvlad Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы. ... т.к. увидел ваше недостаточное понимание механизма работы версионности Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;) hvlad Если вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима. vadiminfo Цифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение вот вам обоим ссылка на книжку Там кстати, в конце каждой главы перечислено множество других трудов, гораздо долее монументальных, на которых основана данная книга vadiminfo Например, если блокировочник вынуждает часто коммитить, и разбивать логически единую транзакцию на большое количество мелких транзакций, чтобы повысить призводительность Вот один в один случай, который я привел в первом посте. У Кайта это прочитали, я знаю. Так вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов) vadiminfo Буду проверять так или нет. Обращаться к разным источникам. Но буду считать, что такое мнение есть в литре Замечательная позиция. А теперь, почему-бы вам не почитать что-нибудь про mssql, и получить собственную позицию по нему, а не клонированные мысли Кайта ? vadiminfo Кроме того, приблизительность для типовых приложений БД - редкая роскошь. в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 14:57 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
авторТак вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов) извиняюсь, но вам верить - себя неуважать ... Of course, committing frequently to release locks has a cost. The commit frequency must be a compromise between availability and concurrency of data, and also performance of DB2 applications. (C) IBM дальше почитайте 5.1.3 When to Commit? http://www.redbooks.ibm.com/redbooks/pdfs/sg244725.pdf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 15:14 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerS hvlad Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы. ... т.к. увидел ваше недостаточное понимание механизма работы версионности Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;)Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement , по крайней мере при конфликте блокировок. Если вы всегда работаете с неявными тр-циями, это не значит, что между statement и transaction можно поставить знак == StalkerS hvladЕсли вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима. vadiminfoЦифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение вот вам обоим ссылка на книжку Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :) С таким же успехом я могу дать ссылку на исходники IB - там меньше и язык проще Формулировку теоремы привести можете ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 15:23 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
serg99 В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации". Почему Вы не хотите написать как это сделал Dooma в инструкциях на стандартном языке? я бы давно уже проверил. А так нужно догадывться и все равно есть риск, что не совсем так понял. Ведь мне писать нужно - не желательно в холостую. serg99 Я не ожидаю конкретного состояния счета. Надеетесь, что выпадет та последовательность какая надо? Денег больше? Типа рулетки? К сожавлению заказчики, среди которых только 15% адекватные, как тут кто-то сказал, могут думать иначе. StalkerS вот вам обоим ссылка на книжку Там кстати, в конце каждой главы перечислено множество других трудов, гораздо долее монументальных, на которых основана данная книга Посморю. Спасибо. Вы уверены, что там есть про пользу Ораклу от эскалации блокировок в некоторых случаях? Никаких других роешений нет? StalkerS Вот один в один случай, который я привел в первом посте. У Кайта это прочитали, я знаю. Так вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов) Да у Кайта - это Вы как в воду глядели. Хорошо, но я видел другое. Блокировки их замучали и они делали не так как Вы говорите. Ну пусть они не опытные. Но у нас с Вами Рел модель - одно из ее достоинств - меньшие требования к квалификации. StalkerS Замечательная позиция. А теперь, почему-бы вам не почитать что-нибудь про mssql, и получить собственную позицию по нему, а не клонированные мысли Кайта ? Я на, самом деле, стараюсь читать общие книги по БД. И их у меня больше, чем по Ораклу. Мне важно где находится Оракл по отношению к другим СУБД. Конкретно по mssql я читал когда-то справки. Правда это был 7. И даже меня иногда приглашали, када что-то долго нее получалось. Потому видел как они работают. Ход их мысли. Как могу, и с Вашей помощью в том числе, стараюсь быть в курсе и про mssql. Без этого форума, например, не знал бы про Юникон вообще в настоящее время. ТО что я не со всем соглашаюсь еще не значит, что я не пытаюсь найти какие-то рациональные зерна для себя. StalkerS в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят Боюсь, что не пойму до тех пор, пока не будет точно установлено, что свойство транзаций - изолированость является необыкновенно вредной идеей. Пока, однако, все обстоит иначе. И думаю, что если mssql станет истинным версионником (в поздних версиях Юникона), то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 16:26 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Я не Юникон - я Юкон! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 17:03 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Yo!! извиняюсь, но вам верить - себя неуважать ... Это ваше право ! и вообще, при чем здесь DB2 hvlad Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement, по крайней мере при конфликте блокировок. не, что-то вы совсем запутались, и других пытаетесь ;) При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся. Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируется. hvlad Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :) во-первых, все читать совершенно не обязательно (особенно про recovery) во-вторых, английский язык полезно знать ;) в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьеме vadiminfo Посморю. Спасибо. Вы уверены, что там есть про пользу Ораклу от эскалации блокировок в некоторых случаях? Никаких других роешений нет? посмотрите вышеуказанную ссылку, хотя там все на примере mssql vadiminfo Да у Кайта - это Вы как в воду глядели. не в воду, а в книгу Кайта ;) vadiminfo Блокировки их замучали и они делали не так как Вы говорите. Ну пусть они не опытные. Но у нас с Вами Рел модель - одно из ее достоинств - меньшие требования к квалификации. Это где вы такое достоинство выкопали ? Конечно, если посадить студента-двоечника проектировать финансовую систему банка, то такой банк долго не проживет. С другой стороны, конечно, все мы начинали с азов, и продолжаем узнавать что-то каждый день. Поэтому всегда возможны крайности, например использование транзакций там где не надо (берут и заворачивают огромную ХП в транзакцию, в результате чего deadlock'ки плодяться как тараканы), или указанный выше пример с разрубанием действительно нужной транзакции на части, в результате чего дэдлоки изчезают, зато дебет начинает не сходиться с кредитом. Но сервер в этом обвинять все-таки нельзя ! vadiminfo ТО что я не со всем соглашаюсь еще не значит, что я не пытаюсь найти какие-то рациональные зерна для себя. аналогично vadiminfo то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение. с появлением версионности, использование грязного чтения и в самом деле должно скатиться практически к нулю, так как немногим сложнее можно получить полностью согласованную картину. Тем не менее, не забывайте, что не все работают в банках, и далеко не все отчеты требуют точных цифр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2005, 21:28 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerS не, что-то вы совсем запутались, и других пытаетесь ;) При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся. Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируется. Не знаю как в Юконе, а в Oracle идет нормальный exception. Это означает, что окатывается только ОПЕРАТОР, вызвавший ошибку. Конечно программист может обработать исключение по разному, но то что ПРОГРАММИСТ вызовет rollback при обработке исключения, не означает что Oracle при возникновении ошибки откатывает всю транзакцию. Так-что это Вы слегка запутались ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 08:05 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ????????????? hvlad Да. Только на время изменения. И не запись, а страницу, на которой она лежит. Это так сложно для понимания ? Понять это действительно сложно, ибо : 1. Без блокировки изменённой записи при коммитите уже позно разруливать чьи изменения нужно принимать. Чьи изменения ,по вашему, нужно принимать при коммите ??? Первого или последнего изменившего запись ?? А что делать тому кто пролетел ? 2. Берём FB1.5... в одной сессии говорим Код: plaintext Берём вторую сесиию : говорим Код: plaintext Код: plaintext 1. Это то что вы называете "нет блокировок" ????????????????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 09:29 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerS hvlad Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement, по крайней мере при конфликте блокировок. не, что-то вы совсем запутались, и других пытаетесь ;) При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся. Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируетсяДуэль, дуэль Итак, следственный эксперимент: Сессия №1 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Её результаты Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Здесь таблица t заблокирована Сессися №2 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. По вашим словам, оператор (2) должен откатить всю тр-цию, в том числе оператор (1). Смотрим результаты Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Ась ? Можете повторить на Юконе или на Оракле, дарю StalkerS hvlad Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :) во-первых, все читать совершенно не обязательно (особенно про recovery) во-вторых, английский язык полезно знать ;) в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьемеВо-первых, я не собираюсь качать кучу неизвестно чего, неизвестно для чего, уж извините. Во-вторых, с английским на этом уровне я проблем не испытаваю, спасибо за совет В третьих - я схожу туда... чуть позже :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:22 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Так-что это Вы слегка запутались Про Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше) Получается, serializable в Oracle не полный эквивалент snapshot /////////////////// Все это очень хорошо работает при читающих запросах, однако при записи могут возникать конфликты. Если при выполнении обновления snapshot-транзакция доберется до записи, заблокированной другой транзакцией, то, возникнет конфликт версий. Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot-транзакция откатывается, поскольку если она изменит данные более «молодой» транзакции и продолжит работу, вполне возможен феномен утерянного обновления. Сместить эти транзакции друг относительно друга во времени и считать snapshot-транзакцию более «молодой» тоже не получится, так как блокирующая транзакция могла добавить записи, удовлетворяющие условию выборки snapshot-транзакции, а значит, все snapshot-запросы должны были эти записи увидеть. То есть snapshot-транзакция все равно должна выполниться заново, с более поздней временной меткой, чтобы увидеть все изменения, внесенные блокирующей транзакцией. ////////////////////// ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:33 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
2 hvlad с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:35 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
ZaxxВы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????Сколько раз мне это повторить ? Столько, сколько знаков вопроса ? Zaxx hvlad Да. Только на время изменения. И не запись, а страницу, на которой она лежит. Это так сложно для понимания ? Понять это действительно сложно, ибо : 1. Без блокировки изменённой записи при коммитите уже позно разруливать чьи изменения нужно принимать. Чьи изменения ,по вашему, нужно принимать при коммите ??? Первого или последнего изменившего запись ?? А что делать тому кто пролетел ? Может быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции, или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции. Zaxx2. Берём FB1.5... в одной сессии говорим Код: plaintext Берём вторую сесиию : говорим Код: plaintext Код: plaintext 1. 2. 3. 4. Это то что вы называете "нет блокировок" ?????????????????А где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше. А может вам в FAQ сходить ? Здесь этого навалом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:35 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Все принимаем на веру ? А самому проверить не судьба ??? Вы поняли автора слишком буквально Как правило, особенно начинающие разработчики, реагируют на подобный exception откатом транзакции. Но при чем тут Oracle и Yukon ??? Кстати, выше приведен пример работы Юкона если я не ошибаюсь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:37 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerSПро Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше) StalkerS...Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot- транзакция откатываетсяАвтор статьи должен признать, что имел в виду оператор, а не тр-цию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:40 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerS2 hvlad с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)У кого обед заканчивается, а у кого завтрак ещё не переварился ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 10:41 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
StalkerS посмотрите вышеуказанную ссылку, хотя там все на примере mssql Ссылку посмотрю. Но звучало так, что якобы и Ораклу есть польза от ЭБ. Я про то, что ,возможно, у Оракла для решений проблем, найдутся другие решения, кроме ЭБ. Так как от ЭБ все-таки все еще ожидается много вреда. Т.е. такое лекарство может оказаться хуже болезни. StalkerS Это где вы такое достоинство выкопали ? Конечно, если посадить студента-двоечника проектировать финансовую систему банка, то такой банк долго не проживет. Ну как это где? Вот за иерархическую или сетевую БД (а возможно и ООСУБД) посадить студента двоечника совсем сложно - банк бы вообще бы не дождался никогда системы. Вот в чем краегольный камень успеха РМД в плане продвижения на рынке. А Вы говорите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 11:23 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
hvladМожет быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции, или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции. Дык это по вашему не блокировка ???? hvladА где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше. Дык, а что-же тут блокируетcя ??? Именно запись. Она заблокирована для записи другой сессией. И называется это именно блокировка, а не "конфликт обновления". Если вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 11:28 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
Zaxx hvladМожет быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции, или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции. Дык это по вашему не блокировка ????Нет. Ни по какому. Это - ожидание завершения конкурирующей тр-ции. Блокировкой записи тут не пахнет, абсолютно. Это может быть похоже на блокировку записи, но это не так, совсем. Если я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ? Zaxx hvladА где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше. Дык, а что-же тут блокируетcя ??? Именно запись. Она заблокирована для записи другой сессией. И называется это именно блокировка, а не "конфликт обновления"Нет. В IB\FB нет ни понятия, ни механизма блокирования записи (в смысле создания объекта "блокировка записи" и работы с ним). Сколько можно воду в ступе толочь ? Вы читали хоть что-нибудь о MGA ? ZaxxЕсли вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник).Я говорю только то, что я говорю. Не нужно проводить аналогии с блокировочниками, тем более не корректные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 11:54 |
|
||
|
Различия в работе версионных механизмов в Oracle и Yukon
|
|||
|---|---|---|---|
|
#18+
hvladЕсли я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ? Вы спорите ни о чем. Знаете старую фразу - "если нечто плавает как утка, крякает как утка и несет утиные яйца, значит это утка"? В Вашем случае возникнет миллион незакоммиченных версий. Причем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2005, 12:11 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32972904&tid=1553835]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
26ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 167ms |
| total: | 261ms |

| 0 / 0 |
