How to tackle the problems of optimistic locking (Versioning) in hibernate?

I know, that can use the following code to implement optimistic locking, however the disadvantages are that the user or application must refresh and retry failed updates. How to tackle the issue so users or application do not trapped in such failed errors?

public class User {

 @Id
 private Long id;

 @Version
 private Long version;


}

Answers


You can use either optimistic locking using versions or pessimistic using DB locks.

Optimistic means that you hope that concurrent change will never come and if it will, one of these user will win and second (or third etc.) will have to update it's entity from DB and perform the change again. As it does not use any additional locking at DB layer, it just provides great throughput of your system/DB.

On the other hand you can use pessimistic locking which locks the entity once user starts to edit the entity. The lock is released at the same time as underlying transaction get commit/rollback. Nobody can fetch the entity from database so mostly the user needs to wait until commit of transaction of another user. Obvious advantage is no such errors any more, drawback is lower throughput.


Need Your Help

LibGDX Sprite Batching and adding in new sprites at runtime

libgdx sprite spritebatch batching

I am a new programmer working with the libgdx engine and was wondering about the act of sprite batching. specifically how to add sprites to the batch for drawing during a programs lifecycle. so far...

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.