Изглежда, че сте конфигурирали Hibernate да използва оптимистичен контрол на паралелността . Това означава, че вашата таблица с потребители има поле за версия, което Hibernate увеличава при всяка актуализация на ред.
Най-вероятно вашата транзакция започва в началото на HTTP заявката и завършва в края на HTTP отговора. Това означава, че процесът на редактиране на потребител се състои от две транзакции:една транзакция за попълване на уеб формуляра и една транзакция за запазване на промените.
В този случай промяната на нивото на изолация на базата данни няма да има никаква полза. Най-вероятно всичко, което ще получите, е по-лоша производителност и мащабируемост .
Не е лошо да имате StaleObjectException с. Той отразява реалния свят - хората всъщност работят върху едно и също нещо от време на време и могат да възникнат конфликти. Въпросът е, когато бъде открит конфликт, как да го разрешите по начин, който удовлетворява крайните потребители? Може ли да се разреши без помощта на потребителя?
Възможните стратегии могат да бъдат
-
презапишете промените на предишния потребител (често не това, което искате - следователно необходимостта от контрол на паралелност),
-
показва съобщение за грешка с молба от потребителя да опресни и да извърши отново промените си,
-
автоматично обединяване на промените, без да се презаписват промените на предишния потребител (понякога е възможно)
-
информирайте потребителя за неизползваемостта на неговите данни и му предложете начин ръчно да обедини промените си
Всичко зависи от контекста.
