Здравствуйте, RushDevion, Вы писали:

M>>Есть решение получше или всё же это нормально?

RD>Имхо, этот вариант борьбы с concurrency изначально порочен.
RD>Откуда тебе знать, что такая подмена значений не поломает бизнес-логику в целом?
RD>Например, если на основе "старых" значений из конфликтующей сущности были сделаны изменения в других таблицах или вообще в сторонних системах.
RD>Как быть уверенным, что поменяв значения в cath() {...}, ты снова не отхватишь concurrency exception, который уже не перехватить?

RD>А касательно правильного подхода, it depends.
RD>1. Если это фоновый обработчик. Типа раз в минуту взять данные из базы, пошуршать, положить обновленные данные в базу. Тогда проще сделать ретрай всей бизнес-транзакции: прочитать-изменить-сохранить.
RD>2. Если это сохраняется из UI, то можно
RD>2.1 Показать юзеру ошибку: "Версия данных в БД отличается от текущей. Перезагрузите страницу." Реализация сведется к простому перехвату exception и показу сообщения.
RD>2.2 Показать юзеру ошибку: "Версия данных в БД отличается от текущей, обновить из БД?" Это сведется к перехвату exception, вытаскиванию актуальных БД-значений и запихиванию их в поля на форме редактирования, если пользователь выбрал "Обновить из БД".


тут работа из юая идет, просто 2 шага и первый из-за большого кол-ва скл кода сделали в виде процедуры которая в одном месте апдет таблы делает, которую потом же апдейтит энтити обновленным значением.
то есть юзер тут ничего не изменит.
тут вариант видимо перенос логики из энтити в даппер какой-то который не имеет оптимистичных блокировок либо как прочитал тут

Автор: scale_tone
Дата: 03.12.13

про паттерн какой-то