Victor Metelitsa
Жуткая кривота и то, и другое. В первом случае существует select for update nowait, и приличное приложение немедленно получит ошибку, если ему заблокировать не удалось. В таком случае оно может перечитать данные простым select'ом. Но это просто неудобства. Во втором случае это натуральный ужас. Почему работа по редактированию пропала? Когда знаем и текущие значения в базе, и значения, введённые юзером, почему их ему не показать и то, и то одновременно, и не помочь?

Я пытался концепцию пояснить и намеренно уклонялся от деталей. Тока для иллюстрации.
nowait - опция конструкции for update. В моем тексте, так как я не сказал, что вторая непременно зависнет пока первая не разблокирует (for update без nowait). Это уже кто какой сценарий придумает в зависмости от своей специфики требований. Второй селект - тем более детали конкретных сценариев, но я вроде писал что читать, т.е. простой select канает в Оракле, потому не отрицал этого. Так что не понял Вашу мыстль. Я не пытался написать сценарий на все случаи, и не считаю что он должент быть обязательно один.
Т.е. главное, что окно для редактирования (а не любое) не сможет прочитать (хоть с nowait хоть без поскоку есть for update) раз разработчик решил юзать писсиместическую блокировку. Нет он, конечно, может в слкучае если не проканает for update, выполнить просто select в том же окне, но написать что редпактирование не возмрожно, но это уже излишние дополнения к конценпции.

Что до второго, то не знаю, почему, но пропадает на практике из того что я видел. Ну если Вы юзаете стандартные средства. Про Дельфи писал. Ну у Аксцесса есть, наскока помню. Пропадает.
Ну потому и термин оптимистическая, что это не часто. Ну если придумаете как сохранить,то наздоровье. Но думау, это дополнительные усилия, раз на них не пошли стандартные компоненты. Возможно, это уже буит какая-то типа сравнительная блокировка - юзер два часа буит разницу в новром и старом искать, потом, возможно, искать первого, кто это написал и согласовывать с ним. Живо себе это представляю.

Victor Metelitsa
Юзера могут быть разведены организационно. Скажем, двум юзерам дали по пачке документов, они занимаются вводом. Третий юзер занимается проверкой. Четвёртый делает отчёты за прошлый введённый месяц. Они друг другу не мешают, и блокировки не причём.

Извините, подвинтесь. Вы можете организовывпать скока угодно. Однако, вопрос что должно делать приложение, если они не развелись, к примеру случайно, остается. Тем более, что я наблюдал, как правило, именно када разработчики и слыхом не слыхивали ни о каких оптимистических и писсимистических блокировках. Люди думали и до ситх пор думаут, что-то то изобрели и не в курсах, что кое-что не учли. Они полагают, раз есть термин "блокировка", то этим должна заниматься или СУБД, или выдумыввали плохие слова про юзеров и их организацию. Т.е. они типа че-то изобрели, от компонентов, которые на автомате оптимистическую включают отказались.