optimistic locking - JPA: OptimisticLockException and Cascading -
in current project use spring data jpa hibernate consider more general question should cover "plain" jpa.
i'm uncertain how should deal optimisticlockexception
when using @version
.
due how application works relationships have cascadetype.persist
, cascadetype.refresh
, others have cascadetype.merge
.
- where handle
optimisticlockexception
as far can tell handling on service layer won't work cascadetype.merge
because offending entity 1 needs handled service ( have service per entity class).
problem i'm creating framework , hence there no layer above service "delegate" user of framework seems "weak , lazy".
- determine offending entity , fields changed
if optimisticlockexception occurs, how entity caused issue , fields changed?
yes, can call getentity()
how cast correct type if cascadetype.merge used? entity of multiple types, if/switch instanceof
comes mind seems ugly hell.
once have correct type need differences between versions excluding fields version or lastmodifieddate.
in of mind http 409 stated in case of conflict response should contain conflicting fields.
is there "best-practice-pattern" this?
the whole point of optimistic locking able tell end user: hey, tried save important piece of information, else saved behind back, you'd better refresh information, decide if still want save , potentially enter new values, , retry.
just svn, if try commit file , else committed new version before, svn forces update working copy , resole potential conflicts.
so same jpa : lets caller decide throwing exception. exception should handled in presentation layer.
Comments
Post a Comment