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

Откуда: iBase.ru
Сообщений: 30253
автор
страницы чего ? а главное зачем страницы ?


страницы данных и индексов. Две транзакции меняют данные на одной странице записей таблицы. Параллельно они же не могут это делать. соответственно доступ к странице в памяти сервера "монополизируется" на время изменения этой страницы одной транзакцией. Все.

автор
ну и о котором версионнике речь ?


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

если иметь в виду IB/FB, то блокировок на уровне записей в нем нет. Тогда он "чистый версионник"? Или нет?
26 сен 06, 13:14    [3184478]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Yo.!!
Garya

Теперь рассмотрим "специфический случай" обработки транзакции блокировочником. Допустим, в начале транзакции мы создаем временные таблицы и переписываем в них все данные, которые нам потребуются в процессе выполнения транзакции. Измененные и новые значения мы также записываем во временные таблицы. Перед завершением транзакции переписываем результат в рабочие таблицы. Чем в корне такая работа отличается от работы "версионника"?

тем что "это" работать не будет, помнится Злой тут красиво расписал почему.

Увсе замечательно работает. Особенно если прямыми ручками брать подходящее решение под подходящую задачу и пользоваться тем, что есть в арсенале СУБД. Я понимаю, что легче и быстрее всего "слить" решение проблемы на универсальный механизм и "радоваться" средней скорости выполнения, но иногда все таки бывает полезнее и самому думать головой. Вот простой пример - крутиться у меня сейчас на блокировочнике ASA 9 интернет магазин, где в обе стороны со стороны фронта веб пользователи резервируют товар на складе, а операторы/админы со стороны админки управляют каталогом товаров, складом и заказами. Иногда бывает раз в пару месяцев и деадлок проскочит, когда идет массовый ввод как новых товаров на склад, так и изменение информации по существующим благодаря тому, что оформление заказа в вебе затянутая по времени многошаговая операция (желание заказчиков). Но даже такой одинокий деадлок является правильным, так как он всегда откатывает сессию веба и никогда администраторской консоли, ни разу не было (и не будет), чтобы клиент заказал себе несуществующий или уже зарезервированный на складе товар (по условиям задачи товары появляются и изчезают со склада очень быстро). Причем на просмотр сайта вообще для веба стоит грязное чтение, ибо юзеру здесь не критично, поменялось ли тоже название товара, пока грузилась его страничка. А вот где начинается работа с ценами, наличием на складе и оформлением заказа - тут уже осуществляется нужный подьем уровней изоляций вплоть до SERIALIZABLE. Работает ... и ведь быстро работает, если учесть, что одновременно с базой работают порядка 30 операторов и в часы пик свыше сотни веб пользователей. И вот что интересно - недавно вышла ASA 10, в которой теперь есть поддержка уровня изоляции SNAPSHOP, где судя по куче способов управления видимостью информации этого уровня изоляции и штатным сборщиком мусора в БД, разработчики видимо решили реализовать не популярную примочку, а полноценный механизм ... но как бы до сих пор я так и не придумал, где мне этот SNAPSHOP может понадобиться, с учетом того, что включая этот режим я гарантированно потеряю скорость. Длинные отчеты вроде как у меня и на предрассчитанных аггрегатах неплохо недлинными получаются (опять же помимо версионности в 10-ке ввели материализованные представления, что позволит частично избавиться от своих решений аггрегатов).

Может быть Вы Yo! мне подскажите как человек с версионным опытом, почему я получил в довесок к блокировочнику версионник и никак не могу понять, зачем оно мне нужно и когда это стоит включать ? И почему кстати сколько я не видел БД на Оракле, написанных в том числе в стенах диллеров Оракла, всегда для большого обьема данных БД разделяют на 2 части - на ту, которая собирает и считает (для OLTP) и ту, которая хранит входящую информацию и предрассчитанные аггрегаты для отчетов (для OLAP). Зачем их разделять на Оракле, геммороится с синхронизацией между БД, если есть такая классная фича, как писатель, который не блокирует читателя ? ;)
26 сен 06, 13:38    [3184673]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
kdv

страницы данных и индексов. Две транзакции меняют данные на одной странице записей таблицы. Параллельно они же не могут это делать. соответственно доступ к странице в памяти сервера "монополизируется" на время изменения этой страницы одной транзакцией. Все.

ну "типа" версионник оракл блокирует только на уровне строки.

kdv

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

если чистый версионник это Timestamp ordering то там помоему просто по комиту откатывется та транзакция которая наткнулась конфликт.
26 сен 06, 13:58    [3184853]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Garya
Это Check conctraint. Поскольку FieldA и FieldB расположены в РАЗНЫХ таблицах, то не во всех СУБД его можно так просто реализовать.

Пардон, я отвечал таки Dimitry Sibiryakov'у. Но раз уж речь зашла о разных таблицах, то тем более не понял - при чем тут был unique constraint.
А по сути возражения - возражений нет :)

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

Гммм... ща буду ругаться матом :)
На уровне RC описанный выше конфуз возможен в любой СУБД, если не предпринимать дополнительных усилий.
На уровне RR описанного выше конфуза не можен быть, опять таки в любой СУБД (реализующей RR, конечно).
А блокировочник или версионник - это уже детали реализации :). Для этого типа конфуза оно не важно.

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

Нормальный "псевдоверсионник" должен сравнивать не всё подряд, а ...

Неважно что он там должен сравнивать. Главное, что "чистый" (не-псевдо) версионник - могёт рулить конфликтами. Сопстна про что и речь была.

------------------------

2 kdv
о каких блокировках идет речь? версионнику, чистому или "нечистому", блокировки по чтению не нужны, совсем. Блокировок по записи тоже как таковых нет, то есть "заблокированная" изменением запись обнаруживается только при попытке ее update/delete другой транзакцией.

Неважно, берете Вы в кавычки слово "заблокировано", или не берете. Блокировка писателя другим писателем (еще не закомиченным) все равно есть - в "нечистых" версионниках. Хоть блокировкой её назови, хоть конфликтом версий, хоть синенькой пирамидкой.
Хотя вполне можно сделать систему и без этой блокировки, и отлупы слать в момент коммита, а не "при попытке ее update/delete другой транзакцией". Тока наверное это не нужно никому, что в общем-то и логично.
26 сен 06, 14:01    [3184877]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
если чистый версионник это Timestamp ordering

номера транзакций в ib/fb - это и есть timestamp. видимость версий определяется состоянием транзакций, в т.ч. и по "больше", "меньше".

автор
там помоему просто по комиту откатывется та транзакция которая наткнулась конфликт.

есть нюанс. при read-committed можно повторить операцию, натолкнувшуюся на конфликт (если сервер по своей инициативе не занимается самодеятельностью типа отката транзакций). при snapshot - нет. потому что snapshot не увидит конфликтующую запись даже если ей сделать commit.
26 сен 06, 14:02    [3184888]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
ЛП
Блокировка писателя другим писателем (еще не закомиченным) все равно есть - в "нечистых" версионниках.


мнение принято, спасибо, согласен. но мне бы хотелось услышать ответ на этот вопрос от Garya. что он имеет в виду "чистым" версионником и блокировками в версионнике.
26 сен 06, 14:05    [3184918]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

ЛП

Пардон, я отвечал таки Dimitry Sibiryakov'у. Но раз уж речь зашла о
разных таблицах, то тем более не понял - при чем тут был unique constraint.

При том что при правильном проектировании базы связанные атрибуты (а они
именно связанные) попадают в одну таблицу. И если стоит задача контроля
их уникальности, то эта задача возлагается на unique constraint.
А тем разработчикам БД, у кого руки кривые, не поможет никакой
блокировочник.

Posted via ActualForum NNTP Server 1.3

26 сен 06, 14:10    [3184959]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
kdv

номера транзакций в ib/fb - это и есть timestamp. видимость версий определяется состоянием транзакций, в т.ч. и по "больше", "меньше".

просто в ib/fb кроме TO еще похоже Two phase locking прикручен

kdv

потому что snapshot не увидит конфликтующую запись даже если ей сделать commit.

в смысле не увидит, snapshot это уже MVCC с блокировками на запись. к стате еще у MVCC был Conflict Graph Analysis который тоже кажется без блокировок умеет разруливать конфликты.
26 сен 06, 14:18    [3185025]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ASCRUS

Может быть Вы Yo! мне подскажите как человек с версионным опытом, почему я получил в довесок к блокировочнику версионник и никак не могу понять, зачем оно мне нужно и когда это стоит включать ?

может вы хотите вернутся к той задачке снова ;) ? мне показалось вы все таки поняли чем такое "проэктирование" черевато в жизни ?
На счет магазина - я в полне допускаю что 100 вебных юзеров вполне могут создать аж 2 tps, которые вполне можно выстроить в очередь и обрабатывать через джоб, отказавшись от консистентных отчетов ... но то что это сейчас работает мало мне о чем говорит ...

ASCRUS

И почему кстати сколько я не видел БД на Оракле, написанных в том числе в стенах диллеров Оракла, всегда для большого обьема данных БД разделяют на 2 части - на ту, которая собирает и считает (для OLTP) и ту, которая хранит входящую информацию и предрассчитанные аггрегаты для отчетов (для OLAP).

вот уж не знаю почему у вас избирательное зрение ... могу только предположить.
26 сен 06, 14:27    [3185117]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

Откуда: Москва
Сообщений: 33197
Блог
Yo.!!
kdv

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

если чистый версионник это Timestamp ordering то там помоему просто по комиту откатывется та транзакция которая наткнулась конфликт.
А конфликто-то каким все-таки образом выявляется, если блокировок в принципе нет?
26 сен 06, 14:32    [3185161]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
Garya
А конфликто-то каким все-таки образом выявляется

объясняю на примере IB/FB:

1. транзакция X выполняет update
2. движок находит обновляемую запись
3. находит запись или пакет версий
4. смотрит на состояние транзакции для самой свежей версии
5.
a) если эта транзакция не active, то update проходит (создается новая версия с идентификатором транзакции X)
b) если эта транзакция active - выдается отлуп. конкретно в IB/FB он звучит как deadlock, и используется в том числе для сообщения о реальных deadlock-ах (взаимоблокирование wait-транзакций на update/delete)
26 сен 06, 14:50    [3185331]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
Garya
А конфликто-то каким все-таки образом выявляется, если блокировок в принципе нет?


http://www.osp.ru/text/302/185218/
26 сен 06, 15:24    [3185616]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

Откуда: Москва
Сообщений: 33197
Блог
ЛП
Если уж беретесь что-то сравнивать, то при сравнении используйте одинаковый уровень изоляции - и в вышеприведенном примере все отличия в поведении версионника и блокировочника исчезнут.
Ок, давайте рассмотрим уровень изоляции SERIALIZABLE. В моем примере всем всё разрешено. Обе транзакции модифицируют совершенно разные данные. Но уровень SERIALIZABLE просто НЕ ОБЕСПЕЧИВАЕТСЯ. Одна транзакция продолжает читать данные, модифицируемые другой транзакцией, она просто "плюет" на заданный уровень изоляции. Когда она дойдет до коммита, тогда - вот тогда ЧТО? Тогда она, наконец, "спохватится" и начнет выяснять, а правильно ли она делала, пока работала. На этом этапе она и проверяет блокировки. И выясняет, что неправильно. И откатывается...
Я согласен, что для приведенного мною примера, который должен вынудить одну из транзакций откатить (хотя бы из-за дедлока), плохо прослеживается одна вещь. Если бы пример был бы не "дедлочный", то стало бы ясно, что если бы СУБД немного "притормозила" одну из транзакций, ей не понадобилось бы ее аварийно откатывать. Возможно, сработал бы откат, но штатный - с адекватной обработкой ситуации. А может быть, удалось бы закомитить обе транзакции, но одной из них пришлось бы немного погодить.
Что лучше - когда СУБД не оценивает возможность параллельной обработки, а просто тупо ее выполняет, после чего часть проделанной работы забраковывает, либо когда СУБД критические операции "притормаживает" таким образом, чтобы они выполнялись не параллельно, а последовательно - но при этом дает возможность выполниться всем операциям?

ПМСМ, однозначного ответа на этот вопрос нет. Иногда хорошо первое, иногда второе.
26 сен 06, 15:31    [3185670]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

Откуда: Москва
Сообщений: 33197
Блог
Yo.!!
Garya
А конфликто-то каким все-таки образом выявляется, если блокировок в принципе нет?


http://www.osp.ru/text/302/185218/
Большое спасибо за ссылку на статью. Очень интересная статья!
И все-таки повторяю вопрос. Чем это не блокировки?:

ROMV
...
3) Завершение транзакции ti (commit) откладывается до того момента, когда завершатся все транзакции, записавшие версии данных, прочитанные ti.
...
2V2PL
...
если операция является финальной для транзакции ti, то она откладывается до тех пор, пока не завершатся: a) все транзакции tj, прочитавшие текущую версию данных, которую должна заменить версия, записанная ti (тем самым устраняется возможность неповторяющегося чтения); b) все транзакции tj, которые записали версии, прочитанные ti (это требуется только во втором варианте алгоритма)
26 сен 06, 15:49    [3185806]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Garya

...

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

...


Почему Вы считаете, что нужно откатывать всю транзакцию целиком? В случае дедлока достаточно откатить только последнюю операцию DML.
26 сен 06, 16:20    [3186103]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Garya
ЛП
Если уж беретесь что-то сравнивать, то при сравнении используйте одинаковый уровень изоляции - и в вышеприведенном примере все отличия в поведении версионника и блокировочника исчезнут.
Ок, давайте рассмотрим уровень изоляции SERIALIZABLE.

Ну давайте рассмотрим, что-ли...
Не совсем понятно, что именно рассматриваем - версионник, или блокировочник?

В моем примере всем всё разрешено. Обе транзакции модифицируют совершенно разные данные. Но уровень SERIALIZABLE просто НЕ ОБЕСПЕЧИВАЕТСЯ. Одна транзакция продолжает читать данные, модифицируемые другой транзакцией

Судя по выделенной фразе - рассматривается нифига не блокировочник

, она просто "плюет" на заданный уровень изоляции. Когда она дойдет до коммита, тогда - вот тогда ЧТО? Тогда она, наконец, "спохватится" и начнет выяснять, а правильно ли она делала, пока работала. На этом этапе она и проверяет блокировки.

Судя по выделенному слову - нифига не гипотетический "чистый" версионник.

Так шта этта... давайте определимся сначала с предметом рассмотрения, а потом уже и порассматриваем чавой-нибудь :))
26 сен 06, 16:24    [3186133]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
AI
Почему Вы считаете, что нужно откатывать всю транзакцию целиком? В случае дедлока достаточно откатить только последнюю операцию DML.

Ахтунг!
Это Вы сами такую транзакцию выдумали, кусочно откатываемую???
26 сен 06, 16:25    [3186141]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
ЛП
AI
Почему Вы считаете, что нужно откатывать всю транзакцию целиком? В случае дедлока достаточно откатить только последнюю операцию DML.

Ахтунг!
Это Вы сами такую транзакцию выдумали, кусочно откатываемую???


При чем тут кусочно откатываемая транзакция? Откат только последней в транзакции команды, в которой детектирована ошибка - нормальное явление в СУБД. Во всяком случае, в оракле, при обнаружении дедлока вся транзакция не откатывается.
26 сен 06, 16:43    [3186296]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
AI
Почему Вы считаете, что нужно откатывать всю транзакцию целиком? В случае дедлока достаточно откатить только последнюю операцию DML.

Ахтунг!
Это Вы сами такую транзакцию выдумали, кусочно откатываемую???


Сам ты Ахтунг
в Oracle есть Savepoint-ы

В случае зафиксированного DeadLock-а откатываются изменения одного оператора. Дальше приложение решает делать commit или rollback предыдущих изменений
26 сен 06, 16:44    [3186300]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Gluk (Kazan)
Сам ты Ахтунг

От ахтунга слышу :)

в Oracle есть Savepoint-ы

Сейв-поинты - сейв-поинтами
Они не только в оракле есть.
В аксесе так вообще есть полноценные многоуровневые транзакции. Но откатываются то они целиком :).

В случае зафиксированного DeadLock-а откатываются изменения одного оператора. Дальше приложение решает делать commit или rollback предыдущих изменений

А при чем здесь "приложение решает"? Если, например, хранимка из пяти DML-стейтментов, обернутых в сериалайзбл-транзакцию. Четвертый из стейтментов рушится. Откуда возьмется какое-то приложение, решающее что-то про коммит и роллбак предыдущих (а заодно и последующих) изменений?
26 сен 06, 17:01    [3186448]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
ЛП

...

А при чем здесь "приложение решает"? Если, например, хранимка из пяти DML-стейтментов, обернутых в сериалайзбл-транзакцию. Четвертый из стейтментов рушится. Откуда возьмется какое-то приложение, решающее что-то про коммит и роллбак предыдущих (а заодно и последующих) изменений?


Ну так, значит, приложение, то есть "хранимка" написана, что просто откатывает изменения.

Легко написать прикладу, которая будет ловить ошибку и передавать ее на рассмотрение персоналу для решения проблемы, оставляя успешно завершенные, но не "закоммиченные" операторы. Транзакция остается открытой и готовой для продолжения после исправления ошибки. Может, правда, это только у ораклоидов так принято приложения писать...
26 сен 06, 17:21    [3186594]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 AI
Легко написать прикладу

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

Речь однако не про то, кто как может в клиентском приложении извратиться. И не про то, кто как может извратиться в управляющем PL/SQL-коде.

Если транзакция шла, шла, да на коммите навернулась (случай, описываемый Гарей), то СУБД, не обладающая искусственным интеллектом, не может сделать ничего, кроме отката транзакции целиком. Я так думаю.
Откуда взялось "достаточно откатить только последнюю операцию DML", что за мифические сейф-поинты на ровном месте выросли - загадка.

Может, правда, это только у ораклоидов так принято приложения писать...

Ну почему ж, среди аксесников тож хватает людей, страдающих избытком интелекта :)
26 сен 06, 17:42    [3186743]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
Если транзакция шла, шла, да на коммите навернулась (случай, описываемый Гарей), то СУБД, не обладающая искусственным интеллектом, не может сделать ничего, кроме отката транзакции целиком. Я так думаю.


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

Кроме того, если в транзакции оператор НЕ ВЫПОЛНИЛСЯ по ошибке, то это означает только то, что именно оператор не выполнился, и ничего более. Транзакция как была жива так и может оставаться дальше живой, и ее можно завершить по commit/rollback. Если, конечно, commit при этом не нарушит логическую целостность блока действий, который под "транзакцией" подразумевает приложение.

одно дело это когда в транзакции выполняются два взаимозависимых update (классика перевода денег с одного счета на другой) - тут как ни крути, никаких commit делать нельзя.
Но если например идет "пакетное обновление" прайса, или вставка данных, то обрамление пакета в одну транзакцию необязательно делает пакет целостным блоком для его обязательного rollback. Приложение вполне может "понять", какой именно оператор не выполнился и почему, а все остальное успешное сохранить по commit.
26 сен 06, 18:04    [3186860]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
ЛП

Если транзакция шла, шла, да на коммите навернулась (случай, описываемый Гарей), то СУБД, не обладающая искусственным интеллектом, не может сделать ничего, кроме отката транзакции целиком. Я так думаю.
Откуда взялось "достаточно откатить только последнюю операцию DML", что за мифические сейф-поинты на ровном месте выросли - загадка.

Может, правда, это только у ораклоидов так принято приложения писать...

Ну почему ж, среди аксесников тож хватает людей, страдающих избытком интелекта :)


В свое время Гаусс сказал о парадоксах Зенона: "Этот грек - идиот!"

Теоретизировать можно сколько угодно. В случае с задачей Гари проблем особых нет. По той простой причине, что чистых версионников не существует. Поэтому всегда найдется оператор предварительного блокирования данных типа select for update, который сделает недоступным работу второй транзакции или вызовет deadlock, приводящий к откату команды, в которой этот самый deadlock найдется. Остальное - уже обсуждали.
26 сен 06, 18:09    [3186883]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 kdv
Но если например идет "пакетное обновление" прайса, или вставка данных, то обрамление пакета в одну транзакцию необязательно делает пакет целостным блоком для его обязательного rollback.

Если у Вас "пакет" не есть что-то обязательно целостное для коммита или роллбака - то и не надо называть этот "пакет" транзакцией :). Оно определению противоречит.
26 сен 06, 18:29    [3186952]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить