At work, we're developing a RESTful application where the data layer will be handled by Hibernate. But we're not sure how to handle updates on entities.
We're planning to do the following:
1) client requests an entity by id
2) Hibernate loads the entity, the requested fields (always with the version) are copied to a DTO that is converted to JSON and sent to the client
3) Client manages some fields and sends the entity (with version number) back to the server.
4) Server receives the JSON that is converted to a DTO.
5) Corresponding entity is loaded from Hibernate and the DTO's props are copied to the entity.
=> The entity is always overwritten even if the version number of the client was set. Does this mean that we always have to check the version number of the client against the version number of the loaded instance by ourselves instead of Hibernate doing this?
In a regular application with sessions, the detached instance is saved in the HttpSession. Whenever the client updates the entity, the instance is retrieved from the HttpSession and some attributes are updated. Whenever Hibernate commits the update, a ObjectStaleException will be thrown if the version number is < the current version number.
The problem here is that we don't have any Http session because we're trying to be RESTful.
Is there a generic solution for handling optimistic locking in RESTful applications instead of checking version numbers by ourselves?
Your strategy is good. Simply copy the version number coming from the client into the loaded entity (or use merge(), which will do the same), and when Hibernate flushes the entity, if the version number has been incremented, you'll have an optimistic lock exception.
You don't need to check anything by yourself. Hibernate does the check for you.