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

А зачем блокировки? В оракле нет необходимости явно указивать начало транзакций.

Оракл на запись сам блокирует строку при update. И только на запись до первого commit (завершение всех транзакций, транзакция автоматически открываетса при первом update,insert, delete).
Для других запросов она не заблокирована (состояние до UPDATE), Разве что кто то захочет обновить туже запись , тогда оракл ждет завершения первой транзакции. В некоторих случаях можно явно заблокировать набор строчек открив курсор с опцией update, по закритию курсора блокировка автоматически снимется. Нужно например когда не хватает остатков с одой партии - тогда берем и блокируем на запись остатки со всех партий и списиваем по мере необходимости. В целом практически не думаеш о транзакциях и блокировках. Просто пишеш бизнес логику. Главное не забивать писать commit завершив необходимые действия или rollback в случае необходимости отменить все действия.

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

Я специально привел очень упращенную схему. Но она работает в 95% или более. И только, в не большом количестве случаев нужно что - то специально придумивать.

Приведу цитату с книги "МакДональд Кониор Oracle PL_SQL для профессионалов практические решения"

"Одно из замечательных свойств языка PL/SQL состоит в том, что любой блок кода
всегда рассматривается как логическая единица работы — он либо выполняется ус-
пешно, либо не выполняется, но выполнен частично быть не может."

Имено ета цитата говорит о том как нужно писать код под оракл.

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

Gluk (Kazan)Выкинь, а лучше сожги (c)
Либо аффтар жжот, либо переводчики, либо (скорее всего) ты


ISBN 5-93772-160-8 (рус.) © Перевод на русский язык. ООО «ДиаСофтЮП», 2005
ISBN 1-59059-217-4 (англ.)
Ст 219

P.S. Я так понимаю ви спец по ораклу...
А к тону сообщений на етом форуме я привык.
Правда представить Вам что есть форумы где люди более толерантны, думаю, сложно.

Gluk (Kazan) Блоки PL/SQL с транзакциями не связаны
Напрямую да.
Необходимая бизнес логика реализуется как раз - такими PL/SQL блоками(функциями, процедурами,пакетами) +тригерами + констрейнами де-факто обеденяя ето все в 1 одну транзакцию.

Я понимаю, что понять, как работает в оракле автоматически то , над чем в MS надо попотеть - сложно. Но ето реальность.

Приведу цитату из книги КАЙТ ТОМ
Oracle для профессионалов
В инете ищите "Tom.Kyte.Oracle.Experts(9,16MB)[by_www.netz.ru].pdf"
ISBN 5-93772-072-5 (рус.) © Перевод на русский язык. ООО «ДиаСофтЮП», 2003
ISBN 1-861004-82-6 (англ.) © Wrox Press Ltd, 2002

"Разница между
тем, как это делается в Oracle и в других СУБД, — феноменальна. Не стоит и говорить,
что ни Informix, ни Sybase не пытались регистрировать результаты в базе данных в ходе
тестирования. Они предпочли записывать результаты в обычные файлы операционной
системы.
Из этой истории можно сделать два вывода: все СУБД существенно различаются, и
при разработке приложения необходимо подходить к каждой СУБД так, будто она для
вас — первая. То, что принято делать в одной СУБД, может оказаться ненужным или
просто не работать в другой.
Работая с Oracle, вы поймете, что:
• Транзакции — это хорошо, именно для их поддержки и создавались СУБД.
• Откладывать фиксацию транзакции можно настолько, насколько необходимо. Не
надо стремиться к коротким транзакциям с целью снижения нагрузки на систе-
му, поскольку длинные или большие по объему изменений транзакции не нагру-
жают систему. Правило следующее: фиксируйте транзакцию тогда, когда это не-
обходимо, и не раньше. Размер транзакций диктуется только бизнес-логикой.
• Удерживать блокировки данных можно столько, сколько необходимо. Для вас это —
средство, а не проблема, которой надо избегать. Блокировки не являются огра-
ниченным ресурсом.
• Блокирование на уровне строк в Oracle не приводит к дополнительным расходам
ресурсов.
• Никогда не нужно повышать уровень блокировки (например, блокировать таб-
лицу вместо блокирования строк), поскольку "так лучше для системы". В Oracle
для системы так лучше не будет: ресурсы при этом не экономятся.
• Одновременный доступ к данным и их согласованность не противоречат друг
другу. Всегда можно получить результаты быстро, и при том корректные."


От себя добавлю
1) Когда идет речь о блокировках в оракле ето в 99.9% блокировки вызвание DML, или в режиме for update (делаются не явно)
2) Об уровннях изолированности транзакций я в курсе. Повторюсь об етом смело можно забыть, если пишеш по оракл.
3) Следующая крититика будет конструктивна только после того, как вы прочитаете выше упомянутую книгу раздел 3 и 4. Займет минут 30. Может что то и интересное для себя почерпнете.

Gluk (Kazan)olehRОт себя добавлю
1) Когда идет речь о блокировках в оракле ето в 99.9% блокировки вызвание DML, или в режиме for update (делаются не явно)
2) Об уровннях изолированности транзакций я в курсе. Повторюсь об етом смело можно забыть, если пишеш по оракл.
3) Следующая крититика будет конструктивна только после того, как вы прочитаете выше упомянутую книгу раздел 3 и 4. Займет минут 30. Может что то и интересное для себя почерпнете.

Вот от себя зря добавил. Да и цитата из Кайта имеет более миссионерское чем техническое значение. И весьма лукава в отрыве от контекста :)

В чём лукавство? Я могу подписатся под каждым словом. Все верно на 100%.

Блокирование на уровне строк в Oracle не приводит к дополнительным расходам
ресурсов.

Почитай ка, что пишет Кайт по поводу отложенной очистке блоков? По твоему это не дополнительные накладные расходы???

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

Ты серьезно думаешь, что никто кроме тебя здесь не читал Кайта???

Я ето и не утверждал.

Да, версионник не может быть на 100% безплатным.
Вы ище вспомни delete и rollback. Да есть накладные расходы.
Я же утверждал, что писать бизнес приложение проще без того что бы думать: "мне проще(быстрее) заблокировать таблицу(таблицы) или блоки (строк)"

P.S. Ну и много здесь людей используют MS как версионник, и не используют ручные блокировки?