Имхо, этот вариант борьбы с concurrency изначально порочен.
Откуда тебе знать, что такая подмена значений не поломает бизнес-логику в целом?
Например, если на основе "старых" значений из конфликтующей сущности были сделаны изменения в других таблицах или вообще в сторонних системах.
Как быть уверенным, что поменяв значения в cath() {...}, ты снова не отхватишь concurrency exception, который уже не перехватить?
А касательно правильного подхода, it depends.
1. Если это фоновый обработчик. Типа раз в минуту взять данные из базы, пошуршать, положить обновленные данные в базу. Тогда проще сделать ретрай всей бизнес-транзакции: прочитать-изменить-сохранить.
2. Если это сохраняется из UI, то можно
2.1 Действовать как в п.1, т.е. считаем что last write wins и делаем цикл прочитать-применить изменения-обновить до тех пор, пока не пройдет без ConcurrencyException.
2.2 Показать юзеру ошибку: "Версия данных в БД отличается от текущей. Перезагрузите страницу." Реализация сведется к простому перехвату exception и показу сообщения.
2.3 Показать юзеру ошибку: "Версия данных в БД отличается от текущей, обновить из БД?" Это сведется к перехвату exception, вытаскиванию актуальных БД-значений и запихиванию их в поля на форме редактирования, если пользователь выбрал "Обновить из БД".
