Посмотри доки, например здесь
http://www.csee.umbc.edu/help/oracle8/server.815/a67775/ch9_tran.htm

Есть (как минимум) 3 варианта

-- все селекты делаются FOR UPDATE (пессимистик лок).
Не рекомендуется при частых запросах, особено если
кто из "писателей" любит пить кофе по 2 часа бросив
комп с открытым документом.

-- трансактион левел - СЕРИАЛИЗАБЛЕ (оптимистик лок).
Вполне удачный вариант во многих сутиаций, но здесь
может не подойти : отбой выдается при попытке записи
на измененый рекорд (то есть кто-то насиловал статью
зря). Кроме того в этом режиме транакции могут жить
только несколько минут (зависит от нагрузки).

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

ЙЙ

Ne sovsem soglasen s
<quote>
В третьем случае можно обойтись без дополнительных полей вообще. Перед посылкой основной транзакции просто сравниваете данные строки перед модификацией с тем, что есть в базе (методика постоянно используется в html'ных формах). Если есть разница - строка менялась и клиенту надо дать предложение на перезапрос, иначе начинать транзакцию. Недостаток - надо иметь на клиенте старую версию строки и отсутствие таймаута. Впрочем, нормальный администратор сам выставит таймауты на подобные "висюки".

В случае с лишними полями не забудьте ставить commit на строку в приложении сразу после их изменения иначе получите ту же блокировку.

Вопрос - все это вам надо? Особенно если учесть, что "насильник" все равно выяснит, что работал зря (случай и второй, и третий с этой точки зрения ничем не отличаются).
</quote>

Kak sledyet iz nachal'nogo voprosa, zadacha stoit v
obrabotke "long transactions in multi-user environment",
kogda redactirovanie mozhet zaniat' minuty-chasi.
V takoi situacii database transactions and TX level
NE MOGYT rabotat' -oni trebuut "stateful connection" design.

Long transactions dolzhny bit' stateless po otnosheniy k klienty
i dolzhni bit' sdelany s pomosh'u dopolnitel'nix poley
(status, flags) i ymnoy applikacii.

Variant 2 (TX level = SERILIZABLE) ne predypredit chto rekord
"zaniat". Predlozhenniy variant s soxraneniem starix znacheniy
na kliente ivliaetsia "stateless" optimistik locking no tozhe ne
predypredit o zaniatosti rekorda.

JJ

AL,

Еще предлагаю исключить патологический в нашем случае рецепт set transactions serializable; и не отстаивать свой вариант как единственно верный.
Согласен, и не коим образом не настаиваю. Мы просто обсуждаем преимущества и недостатки возможных решений в не совсем четко поставленной задаче.

Теперь по деталям. Сохранение старых значений - это основное
решение если таблицы менять нельзя. Этот метод
абсолютно правильно будет отрабатывать трансакции.

Наличие флагов/статусов дает дополнительный сервис:
(если он нужен!!!!)
Например, если супервайзор открывает статью, он может получить
сообщение типа: "статья такаята взята на редактирование
В.Пупкиным. 2.5 часа назад. Вы можете (1) открыть для
просмотра только (2) открыть статью для редактирования
и убрать возможность В Пупкина сохранить его редакцию.
(3) выйти из апликации. "

В Вашем варианте тоже не все гладко - вопрос в том, чтО заносить в дополнительные поля. Например, если все пользователи коннектятся к одной схеме (что-нибудь вроде R3, Oracle Applications или любой большой системы) - имя схемы в качестве флага не подойдет. Так же как не подойдет и адрес сессии, если сессии постоянно открываются/закрываются (опять-таки html).

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

ЙЙ