Hello; many people use "DIY" merging. Here's a nice StackOverflow
treatment of the subject:
http://stackoverflow.com/questions/14141156/jpa-merge-in-a-restful-web-application-with-dtos-and-optimistic-locking
When using DIY-merging, typically you have only a couple values received
from, e.g., the web form that represent the user's intent to change only
part of a logical object. For example, given a hypothetical person entity
with 27 fields in it, the user may have only changed the last name. In
that case, in many applications, all you have to work with coming in over
the wire is an ID, a version value representing the version value of the
entity at edit time (if you're doing things right), and the new last name
value. The salient point here is you don't have the full state of the
entity, just a logical command that the user wants effected—"please set the
last name of person ID=4 to 'fred' provided that the person record on disk
is version 3".
In such a case you then ask an entity manager to find the entity with the
specified ID so you can begin the process of setting the last name on the
persistent entity.
But if you're doing things right, you have to manually compare that
persistent entity's version with the version value you have from the web
form to ward off concurrent changes. You, the JPA programmer, are
responsible for doing this, not the JPA provider. That seems odd to me.
Would it make sense to add a find() variant that takes both an ID and a
version and throws an OptimisticLockException if a persistent entity with
those coordinates does not exist? Or am I missing something more
fundamental somewhere in the API that would explain why this is not needed?
Best,
Laird
--
http://about.me/lairdnelson