Home Optimistic locking in a RESTful application
Reply: 0

Optimistic locking in a RESTful application

user1529
1#
user1529 Published in June 20, 2018, 7:35 am

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?

You need to login account before you can post.

About| Privacy statement| Terms of Service| Advertising| Contact us| Help| Sitemap|
Processed in 0.348439 second(s) , Gzip On .

© 2016 Powered by mzan.com design MATCHINFO