Hi,

My wish is to have ability to perform updates and deletes on versioned entities (http://docs.oracle.com/javaee/6/api/javax/persistence/Version.html) without passing actual latest version manually - in this scenario updates\deletes should succeed. If i pass null in version column - hibernate treats entity as transient and perform insert instead of update. Setting actual version value before database operations is not a preferrable solution, since every service would be responsible for locking logic, etc. So i wonder if somebody knows how to workaround this issue.

The default optimistic locking mechanism does not allow you to interact with the version attribute. That's just for Hibernate internal use only.

If you want to bump the version up manually, you have to use OPTIMISTIC_FORCE_INCREMENT.

Anyway, you should never set it to null manually. The only time when the version is allowed to be null is the first time you create an entity.

Therefore, you either have optimistic locking or not, there's no middle ground.

Hi Vlad, thanks for your reply.

Your comment about the irregularity of interaction with the version attribute is 100% correct. However, we found a way to make it work.

In the use case for the described problem we use the version field in the way of:
1) get DTO from user
2) assemble entity from DTO, for the simplicity assume that we do:

In the described scenario, opt locks are working well, and we are able to pass\recieve version from a user. But the desired option is ability not to provide a version at all in some cases and still perform updates\deletes.
Maybe there is an elegant way to automatically set the latest version.

I think you should use merge instead of saveAndFlush.

Merge allows you to fetch the latest entity snapshot, do the merge while still propagating the version, which is actually correct since otherwise you'd lose updates.

If you don't want to set the version by yourself, you need to save the entity in the Session context in between two HTTP requests or use the EXTENDED Persistence Context.

Hmm.. I guess alongside with merge this can be handled with the manual locking mechanism, as described in this article.

I wonder if there is a similar way to control locking in runtime without manually removing @Version annotation (we still need the column to pass the version number to a user).

Nope, you don't need that. That's for checking a different entity version, not one that you changed.

You just need to pass the detached entity that you read in a previous request, and then you don't have to worry about what version it has.