Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

how to prevent multiple users overriding each other operations  RSS feed

 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I read about transaction isolation levels but the thing that comes to my mind is - how do we prevent multiple users overriding each other operations. e.g. if two admin users wants to edit a record for one particular user and both fires updates with different values then one will override another, right? Here the trasaction isolation level won't help. Am I right?
So, how these transaction levels are useful? Please see if you can come up with some examples to explain this...
Regards
Maulin
 
Rashmi Banthia
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maulin,
Any transaction has the ACID properties that includes isolation, so if a update/insert is in transaction it should be isolated.
As far as different isolation levels (Uncommitted Read, Committed Read, Repeatable Read, and Serializable), they determine how long your transaction must hold locks to protect against user changes(updates).
I think there are many articles explaining transactions isolation levels (not necessarily EJB) but the concepts remains the same.
Hope this helps.
Regards,
Rashmi
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rashmi
Thanks for the input but I read about those transaction isolation levels but only those can't solve this "simultaneous update from clients" scenario. Consider the following scenario,
- I have a user profile which is editable by admin role
- I have multiple people on admin role who can modify user profile
- I have Profile entity bean with 3rd transaction isolation level (that solves that repeated read problem)
Now, here, if two admin goes to the site and clicks on the Edit Profile link, sees data and changes and hit 'submit', what happens? I have read this problem on other sites and it makes sense. This has to be solved at application level. Container can't solve it for us. Here, we have to lock the Profile which is being edited by the first admin and then display to the other admin message that says "This profile is being edited by some other admin please try later", you know what I mean?
I saw some timestamp based solutions for this etc but I am looking for more approaches people use. One is of course locking...
Thanks
Maulin
 
Rashmi Banthia
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I'll try and explain my experience with this kind of situation.
There were couple of jobs(in your case - user profile) in the application(client/server) which we wanted only one user run at one point of time. (Each took approximate 5 mins and accessed multiple tables in the database).We wanted to avoid all the locking/deadlock problems that is the reason - only one user at a time.
We created a table checked_out with columns job_name, user_name(Pk-job_name). (in your case one row of this table will be user_profile_job, user_name ) The column user_name is always empty except when user is running the job. Every job begins with updating user_name column in this table and ends with set null to user_name column in the table.
Every job also begins with checking if the user_name for the job is empty, if not your message - "This profile is being edited by some other admin please try later"
I am not very sure if this kind of approach would work for your application (I assume web based app), if so you might want to add timestamp on the table.

Regards,
Rashmi
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right on track. The common term "pessimistic" concurrency means assume the worst - user conflicts will happen often - and prevent them. When one user starts editing, we put some kind of lock on the data so no other user can start editing. That might be a database lock, an entry in a special locking table, a value in a locking field in the regular table, a flag in memory, etc. All have pros & cons.
The term "optimistic" means we think this won't happen often and we're going to do less to avoid the risk. Timestamp schemes are common. The idea is to check that the timestamp on the database matches the one you retrieved when you started editing. If not, tell the user that someone else has updated while they were thinking and they cannot save. They lose a few minutes work. The timestamp compare is easy because you can put it in the "where" clause of your update SQL. Timestamp is not the only way to do this ... PowerBuilder had a neat feature where you could tell it any combination of columns to compare before allowing the update.
The last choice is do nothing and the "last in wins". If two users update the same record, the later one replaces the earlier one, nobody knows it happened. That's probably not acceptable to you.
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rashmi/Stan
Thanks for the responses. Now I see how to solve the problem.
But this arises one more question to me. If this is the case how transaction isolation levels help us? What do they do? I believe that those levels are useful in the following type of scenarios,
- There are multiple users adding to the inventory of items as they supplied to the store.
- Here, users won't need the locking so to say as they just can 'add' number of particular item they put in the inventory BUT they need surity that all goes correctly.
- If one user adds 2 soapboxes for e.g. and other user enters 3 soapboxes then the inventory should have 5 newly added soapboxes.
Here we need to make sure that none overrides other's change. So may be we can specify third level of transaction (I forgot the name) which might buffer one users request of 'add soapbox' and differ the transaction to happen till the other user is done...
I have read all those transaction level from the Ed Roman's book but I don't think I am sure how they are useful if we have this multiple user problem we have to solve anyways..
Regards
Maulin
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Transaction isolation is helful only to a point. When you follow the other common strategy -- keep transactions short -- you end up with the problem you are discussing.
1. User A reads object X
2. User B reads object X
3. User A updates object X
4. User B updates object X *using dirty values*
You can use optimistic locking to solve this problem. Whenever a user reads data, send back the current value of the optimistic column (version number or timestamp). When the user updates data, start by checking that the optimistic column hasn't been changed. If it has, it means some other user has performed an update since the first user read the values. In this case you can optionally allow the user to overwrite the new values from the second user (force update) or block the update and reload the values.
Transaction isolation only keeps two transactions from interfering with each other. Since you certainly don't want to lock the database while the user enters new values (or goes to get coffee, to lunch, or home for the weekend), you won't have a transaction open during that time. Thus, isolation won't solve this problem.
Note that in many applications this never comes up. Most systems don't go that far to protect data integrity. For example, if a user on a website is changing their first or last name, you don't really care if an admin is doing the same thing at that moment. And you can do other things to minimize the likelihood of update collisions.
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David,
I get what you are suggesting. I guess I am clear now about transaction isolation levels etc.
Thank you all for valuable input.
Regards
Maulin
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!