tru551) Никаких дополнительных сеансов затем НЕ создается
....
2) PGA, которая выделяется сеансу
...
3) на современных серверах обычно стоит несколько Гигов памяти

1 - А я и не говорил этого. Я говорил что каждуму клиенту нужен отдельный сеанс на все время работы с документом.
Если блокировка строк не используется , то после открытия документа можно отключить сеанс.

2 - В зависимости от того что делает сеанс, PGA сеанса может достигать нескольких Мб, особенно при использовании PL/SQL

3 - При плохой архитектуре нельзя увеличить производительность просто нарастив память.


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

PS. Заканчиваем.

tru554. блокировку может снять только тот сеанс, что и блокировал, или админ
Это так, но
- это же относится к любым другим блокировкам, не только SELECT FOR UPDATE
- как я уже сказал, если по бизнес-условиям другие пользователи могут только просматривать документ, не имея возможности его редактировать, то это вполне нормально. Более того, любые другие доморощенные способы типа установки флагов НЕ МОГУТ обеспечить соблюдение подобных бизнес-условий, особенно, если с данными работает не только это приложение. При написании другого приложения эти флаги могут не проверяться, не говоря уж о работе через SQL*Plus
Не надо обобщать. Это НЕ относится к любым другим блокировкам документов.
Если Вы не знаете как это сделать без блокировки записей, то это не значит что это нельзя сделать вообще.
Почитайте например здесь

tru551. я имел ввиду блокировки, накладываемые операциями DML. Пока транзакция не завершена (а они бывают длинными - что поделаешь), никто эти блокировки снять не может

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

2. почитал. Как я и сказал - зачем изобретать велосипед, если есть решение от Oracle?
Это частное решение частной задачи - как заблокировать операцию изменения документа.
А над документом могут применяться и другие прикладные операции, изменяющие его состояние.

Конкретно по предлагаемому решению с доп. таблицей...
- генерится лишние UNDO и REDO, что при большом кол. пользователей и документов не есть гуд.
- работа с доп. таблицей потребляет и другие ресурсы - buffer cache и лишняя работа DBRW и LGRW как минимум

Это все по-любому будет при редактировании документа. Причем в сравнении с UNDO|REDO генерируемыми непосредственно изменением документа, эти служебные операции занимают пренебрежимо мало ресурсов, да еще и не зависят от объема документа.

- подобная дисциплина работы должна соблюдаться всеми приложениями, работающими с этими документами, иначе это не имеет смысла. Кроме того, есть еще упомянутый мной SQL*Plus (и другие подобные инструментальные средства), которые эту дисциплину ну никак не соблюдают

Для этого есть триггеры.

Я не отрицаю, что подобные методы в некоторых случаях имеют право на жизнь (в том топике обсуждались условия, что при некоторых обстоятельствах другой пользователь может изменять документ, который редактируется первым пользователем), но при тех условиях, которые упоминал я (документ может одновременно редактироваться только одним пользователем, другие - только смотреть), SELECT FOR UPDATE - наилучший вариант из всех возможных
SELECT FOR UPDATE - решает только одну частную задачу, Вашу. И в ситуации, где разработчик может навязать пользователю свое решение и свести задачу к этой частной, оно применимо.
Но жизнь вносит коррективы. И в условиях когда заказчиков десятки и сотни, и каждому требуется что-то свое, простые стандартные решения, как это, не гибки.

tru55SELECT FOR UPDATE вполне заслуживает право на жизнь
Это немного другая формулировка чем
tru55SELECT FOR UPDATE - наилучший вариант из всех возможных
Неправда ли?

tru554. Для этого есть триггера.
Да конечно, но это еще дополнительная нагрузка на сервер (а мы начинали разговор с излишнего потребления ресурсов, насколько мне помнится). Я уж не говорю о возможности отключения триггера (случайного или преднамеренного)

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

А насчет отключения триггера - если у пользователя есть права на изменение схемы, то защиты от него нет никакой.

tru551. не надо выдергивать из контекста. Про наилучший вариант я говорил именно для описанных мной бизнес-условий

А я не выдергиваю. Он НЕ лучший даже для описанных Вами бизнес-условий.

tru55А вот в этом Вы меня НЕ убедили
:-)
С чего вдруг я должен что-либо доказывать?
Не я утверждал, что мое решение лучшее - не мне доказывать.