tru55 Филипп AIZSELECT ... FOR UPDATE а зачем?
Иногда требуется по бизнес-условиям (например - редактирование одного документа)
Т.е. предлагается держать транзакцию открытой в течении всего времени редактирования документа (а в итоге и перекура и обеда, да помножем на кол-во одновременно открытых документов :)?
Оракл конечно с этим справляется на ура, но только для небольшого числа юзеров - система получается немасштабируемой (экспоненциальное возрастание требований к ресурсам сервера при линейном возрастании кол-ва пользователей).

Для блокировок документов существуют множество других (нетребовательных к ресурсам сервера) способов.

tru55
1. сделать по другому - это как? Кроме того, SELECT FOR UPDATE - стандартный способ, которй Oracle предоставляет разработчику и которым пользуется сам. Зачем еще изобретать велосипед?

2. а где было сказано, что программа позволяет открыть больше одного документа? Лично я считаю, что открывать больше 1 на РЕДАКТИРОВАНИЕ (не на просмотр) не имеет смысла - это неестественно для человека

3. RAM - это что? В терминологии Oracle есть понятие SGA. Какие структуры для этого задействованы в данном случае? Если buffer cache, дык блоки все равно туда читаются, вне зависимости от того, просто я смотрю документ или накладываю блокировки на строки.
UNDO тратится при изменении данных, а не при SELECT FOR UPDATE

4. по поводу пункта 4 - не понял ответа...

1 - а кто сказал что надо изобретать? Взять готовое решение. Их множество и они обсуждались много раз по всему инету и на sql.ru в частности.
2 - это Вы скажите нашим бухгалтерам :)
3 - каждая блокировка документа требует отдельного сеанса, а на них уходит память, а она конечна. Undo - если в ходе редактирования создаются временные данные на сервере.
4 - Еще раз. Все способы имеют недостатки. Но недостаток этого способа - немасштабируемость . При большой нагрузке он играет основную роль.

tru553. каждая блокировка документа требует отдельного сеанса
Ет-т-то еще с какого перепуга?

Если рассмотреть два клиента, то каждому из них сохранения блокировки требуется сохранять сеанс.
4. вот насчет немасштабируемости у меня большие сомнения. Кроме того, я уже задавал вопрос - при каком кол. одновременно работающих пользователей это может сказаться? Несколько десятков, сотен, тысяч?
Поделите память сервера на память одного сеанса.

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