I have played with IBM version strategy and acheived desired final outcome by using @VersionStrategy and explicit @Version field and set such field to not updatable/insertable (an exception being thrown when optimistic locking is detected) however I realised I might be using optimistic locking not in the way it was intended by JPA standard.
JPA allows defining version fields and manages that field value through different strategy implementations. It works fine, throwing optimistic locking exception, when the data in the database has been changed since the entity has been loaded into persistence context within the context of the same transaction. Problem is that I have two applications - web application and backend web service application. The former retrieves data by accessing the latter, shows it on UI allowing user make changes and finally updates database by again calling the web service. The user can work on the form for a long time and I have to detect scenarios when the same data has been modified by other processes. On the UI form (or cached in web app session) I keep version information for my entities which I then pass back in update web service request. My web service then finds entity by its id and sets properties of that managed entity with new values (the form modifies only subset of fields) including original version value (which is passed back). When the value of the version field was modified in the database I am getting an exception, but it is not optimistic locking exception but exception caused by changing version field value, something that is not allowed by JPA. I achieve desired outcome, which is an exception, but it is not the exception type I want. Example: Entity e = em.findById(id); e.setAddress(new value); e.setVersion(old value); // causes an exception due to value strategy "restrict" I tried alternative approach, where instead of finding the entity and updating state of the managed entity I create new entity instance and then merge it. In such case I can set version field as entity is still detached and I get actual optimistic locking exception.Example: Entity e = new Entity(); e.setId(id); e.setAddress(new value); e.setVersion(old value); em.merge(e); Is it then the only correct way of using JPA optimistic locking mechanism (in my specific use case), meaning it is only appropriate to update database state through merge entity operation? -- View this message in context: http://openjpa.208410.n2.nabble.com/Auto-generation-of-the-WHERE-clause-tp7582868p7582990.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
