А почему новую сессию? Можно же вроде текущую форсировать на вычитку объекта из базы.

Каждый раз новая сессия не всегда хорошо.
Так а не понятно как именно ты хочешь разрулить ситуацию?
Вот есть пользователь, котрый поменял данные, но не смог сохранить - Optimistic Lock Exception
Данные которые он вбил все ещё могут жить в UI, это с хибером вообще никак не связано.
Тебе надо перечитать сосотяние из базы что навбивал другой пользователь? Или как ты хочешь разрулить?

Guest1234567890Каждый раз новая сессия -- необходимость. Приложение модульное, а коннекшнов на всех не хватит.
Тогда нужно уточнять что такое "каждый раз". Какждый раз на бизнес транзакцию или каждый раз на операцию с БД?

Guest1234567890 3) предложить перезаписать изменения злодея
По-моему в той же сессии можно получить значение потенциального противника и затереть его своим. Там только надо смотреть как версии разруливаются.

Guest12345678904) померджить свои изменения с текущими.
Для п. 3 и 4 необходимо знать предыдущее состояние объекта.
Зачем? Нужно знать то что пользоователь хотел сохранить, это есть либо на UI, либо в бинах, перед сохранением. И знать что сейчас реально лижит в базе. Это можно получить из сессии, точно метод не помню. Что лежало в базе до изменений обоих пользователей уже никому не интересно.

Guest1234567890А теперь более сложная ситуация -- никто строку не менял, просто умер коннекшн к базе во время обновления. Как теперь вообще откатиться в интерфейсе на старые значения не перечитывая объект?
Это что-то вообще не ясно. Конекшн умудрился здохнуть во время короткой транзакции? Ну так это глобальный файлур. Чего с ним боротся? Данные которые пытались срхранить никуда не исчезли, а создать новое соединение и перечитать последнее состояние разве проблема?