Managing Concurrent Access

Question

I have an application that manages a list of employees. Users(Admins) in the application have the possibility to create and edit those employees . I want to lock the edit access of an employee while an other user is editing him .

I found that i can use optimistic concurrency so when second user try to edit it he can not . The disadvantage of this solution is that the user can waste time on editing the employee (especially if there is many parameteres to edit) and when he clicks on edit button he will get the new version edited by the user before him.

So I am searching a way to manage concurrent access in the code and not in JPA.Like if the user want to access the edit page of the employee X he will recieve a message that the user ADMIN2 is editing this employee now . And he can not access to edit the employee while ADMIN2 still editing the user .

Is there any standards to use to manage this kind of concurrent access . If not how do you think i can manage this concurrent access ?

Uhhmmmm.... http://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking — Kukeltje, Dec 20 '16 at 10:04
thank you but doesnt contain what i need . i am search an other way to manage concurrency then pessimistic and optimistic concurrency . — osselosse, Dec 20 '16 at 14:01

score 1 · Answer 1 · answered Dec 20 '16 at 22:06

There is no build-in way to do this in JPA. JPA2 does support pessimistic locking, but this is a concept linked to transactions, and therefore not what you need.

Also you don't actually want to do this, and if you were around 10+ years ago when (some) source control system used pessimistic locking ('good old source safe), you will know why this is a bad idea compared to modern day Git.

What you really need is a way to merge the concurrent changes, just like a git merge conflict. Instead of throwing away the user's changes (when the optimistic lock insert fails) you send his modified version and the current version from the database back to the UI, and let the user merge the two versions, and save again.

You could also go full out on the history/auditing, both EclipseLink and Hibernate has a way of storing multiple versions of the same entity (basically like Git does), so you can track changes. I you know your way around JPA, and have a good UX designer it is possible to build a system that works much better than any pessimistic locking will - and even if you try to build pessimistic locking using an 'editing' column, you will still need to use optimistic locking in case two uses click the edit button for the same resource concurrently. ;-)

score 0 · Answer 2 · edited Feb 03 '17 at 11:27

If you really want to implement, what you describe, I would add a editing column in the corresponding table where you mark that editing starts. Then before you start editing, you check this boolean and act with your message. In other words: Such a locking on DB level is hardly possible accross multiple transactions and would be a danger (I asume that editing the employee is a long process, far a way from handled inside same transaction) and you best implement it your self (do not forget to remove the editing boolean after saving or after cancel).

Managing Concurrent Access

2 Answers2