vadiminfoПиссимистическая блокировка - конфиликты ожидаются частыми. Тогда предпочтительнее сессиям планирующим менять одну и ту же запись, начинать делать это убедившись, что никто этим еще не начал заниматься. В Оракле есть для этого в SELECT конструкция For Update.
Клиентская прога предназнченная для редактиравования, выполнит не просто SELECT а SELECT For Update. В этом случе любой другой запрос с For Update, а это все , в данном приложении, кто тоже собирается редактировать (тем более обычно в кленте одно окно для редактирования одних и тех же структур данных), и потому тоже юзают SELECT For Update, не смогут выполнить такой запрос, пока первая не разблокирует заблокированный ресурс. Чтение - просто SELECT данных до начала изменений доступно (но это другое окно в приложении).
Недостаток: юзера с помощью окон для редактирования в таком приложении не смогут даже прочитать заблокирование. Тока с окнами для чтений.

Но ведь еще хуже, если бы они смогли часто, два часа редактирвать, а потом получать: "Запись изменена другим пользователем. Измененичя не возможны" - это то, что делает оптимистическая блокировка.
Она потому и оптимистическая, что предполагает, что такое редко произойдет.
Такая блокировка предполагает чтение просто SELECT и сохранение в своих переменных прочитанного. Далее юзер меняет себе спокойно переменные в проге, а вот перед попыткой выполнить сохранение изменений в БД опять производится чтение, для надежности возможно даже с For Update и сравнивается с тем, что было в начале.
Если сопало, то БД обновляентся иначе отепз от сохранения. Вся работа по редактироаванию пропала.
Недостаток: юзер будет обеспокоен тем, что зря старался. Достоинство, он сможет читать оконм для редактирования.
Не создавать же 10 окон, условно говоря, для одной таблы.
Оптимистическая блокировка, часто уже реализованая в компонентах юзаемых для создания клиентом производителем этих компонент. Например, в Директ Оракл Аксесс Дельфи. Ну та пессимичтичную моно наложить, если надо поверх.


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

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

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

Dimitry Sibiryakovпессимистической и оптимистическНу так 2 конекта - 2 транзакции (возможно с разными уровнями изоляции)

И вот оно: лицензионное ограничение количества пользовательских сессий.

А это где? Оракля и DB2 лицензируют поядерно/попроцессорно/посокетно или же как для named users, у каждого из которых хоть по 10 коннектов... а хоть и ни одного коннекта (т.е., работает через connection pooling) - неважно, он всё равно за 1 сосчитается.