JPA: OptimisticLockException i Cascading

W moim obecnym projekcie używam JPA Spring Data z Hibernate, ale uważam to za bardziej ogólne pytanie, które powinno również obejmować „zwykły” JPA.

Nie jestem pewien, jak sobie z tym poradzićOptimisticLockException podczas używania@Version.

Ze względu na to, jak działa moja aplikacja, istnieją pewne relacjeCascadeType.PERSIST iCascadeType.REFRESH, inni teżCascadeType.MERGE.

Gdzie się poradzićOptimisticLockException

O ile wiem, obsługa tej warstwy usług nie będzie działać szczególnie zCascadeType.MERGE ponieważ wtedy obiekt naruszający może być taki, który musi być obsługiwany przez inną usługę (mam usługę dla klasy podmiotu).

Problem polega na tym, że tworzę framework i dlatego nie ma warstwy powyżej usługi, więc mogę po prostu „przekazać” to użytkownikowi mojego środowiska, ale wydaje się to „słabe i leniwe”.

Określ obiekt i pola, które uległy zmianie

jeśli wystąpi wyjątek OptimisticLockException, jak uzyskać, który obiekt spowodował problem i jakie pola zostały zmienione?

Tak, mogę zadzwonićgetEntity() ale jak mam rzucić to na poprawny typ, zwłaszcza jeśli użyto CascadeType.MERGE? Jednostka może być wielu typów, więc jeśli / przełącz się zinstanceof przychodzi na myśl, ale to wydaje się brzydkie jak diabli.

Gdy będę mieć poprawny typ, będę musiał uzyskać wszystkie różnice między wersjami, wyłączając pewne pola, takie jak sama wersja lub lastModifiedDate.

W głębi mojego umysłu jest także HTTP 409, który stwierdził, że w przypadku konfliktu odpowiedź powinna zawierać sprzeczne pola.

Czy dla tego wszystkiego istnieje „wzór najlepszych praktyk”?

questionAnswers(2)

yourAnswerToTheQuestion