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.

  1. 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".

  1. 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

Popular posts from this blog

Why does Ruby on Rails generate add a blank line to the end of a file? -

keyboard - Smiles and long press feature in Android -

node.js - Bad Request - node js ajax post -