Amberit
Подозреваю, что под оптимистической блокировкой Вы понимаете нечто другое. Например, при ведении разного рода справочников это означает, что любой клиент может править любые данные, но в момент сохранения проверяется наличие конфликтов и потерянных изменений. Возможно, в некоторых случаях это и делается на клиенте, но у нас это реализовано посредством ХП, поэтому разработчику приложения глубоко фиолетово, в каких таблицах и каким образом хранятся эти данные. Он передает их в процедуру, и на стороне БД уже проверяется их корректность и непротиворечивость, отсутствие потерянных изменений и т.д.

Оптимистическая - надежда что она редко понадобится, поскольку потеря работы юзера может быть.
Ситуация:
Один пользователь открыл окно на редактирование. Соотвественно прочитал данные в БД и заполнил контролы. И пошел курить. Другой открыл те же записи и изменил данные и сохранил. Первый вернулся, поменял, что-то из того, и тоже сохранил. При этом, скорее всего, изменения второго пропали как бы. Это без блокировки получается. Наблюдал такое в таких проектах.

Чтобы этого не было клиент может в момент открытия сохранить у себя те данные что были при открытии окна. Перед сохранением изменений еще раз запросить данные и сравнить с ранее сохраненными. Если есть разница, то: данные изменены другим пользователем и отказ их сохранять. Это оптимистическая блокировка.

Dimitry SibiryakovvadiminfoНаблюдал такое в таких проектах.
В проектах где нет разграничения полномочий и каждый вносит отбалдовые данные в хаотично
выбранные записи?..

Проекты в которых отказались от рекордсетов (запросов, представлений в коде клиента). Ну в проектах с ХП как описал коллега Amberit.
Это все еще про вопросы об оптимальности с первой страницы.