• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Lost Update/Concurrency issues in web application

 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
ALtgh this is not directly related to exam but this is a question for all the architects/designers.
How would we manage the famous "lost Update" situation in web applications ? The situation : There are two instances A & B working with same set of data or same row in table. Both are viewing the data and now both press edit button. The data is displayed to them and both press update after making some changes.
The person who pressed last , only his data would be updated in the system.
To avoid this we can't lock the row when person is editing,as in web situation we never know when he would press update.

How can we manage this in web applications?

Thanks
Vinay
 
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are several options:

1. Introduce a central service component like LockManager, which maintains some kind of primary or unique descriptive attribute of item being edited. Before allowing edit of data a sanity check is done against this table using the services provided by the component.

You will need to provide some purge, cleanup services of this table.

2. Maintain last update timestamp on every record and use it to reject the updates if it is older than whats present there.

3. Introduce a conflict resolution strategy, where in you present the user with what has change since the user last updated it and allow him/her to accept or reject those changes.

4. OR simply state that the design is based on last write win strategy

May be there are more options available !!!
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I think the second option presented for Deepak is the best.

Vagner
 
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
EJB - Entity Bean CMP automatically supports the above situation.
 
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vinays Singhh:
Hi
ALtgh this is not directly related to exam but this is a question for all the architects/designers.
How would we manage the famous "lost Update" situation in web applications ? The situation : There are two instances A & B working with same set of data or same row in table. Both are viewing the data and now both press edit button. The data is displayed to them and both press update after making some changes.
The person who pressed last , only his data would be updated in the system.
To avoid this we can't lock the row when person is editing,as in web situation we never know when he would press update.

How can we manage this in web applications?

Thanks
Vinay




Pretty easy. This is called optimistic locking. It's explained in many books (i.e. - "Patterns of Enterprise Applications Architecture", "Hibernate in Action", "Data Access Patterns", etc., etc., etc.!) and in many articles in the net.

The simplest variant can be implemented using versioning.

You will need to keep version field with each database row. Each time you are updating it, you will increment 'version'.

Just like in below example.

You show to user page with data which he can modify. As a hidden field you are keeping 'version' (for example it is equal to 10). In next action where you are doing SQL request, it could look the following

UPDATE ... SET ..., version=version+1 WHERE version=10;

So, in case if record _was_ modified before, it will not be changed because of above mentione request. And you will be able to do some additional request to find that out and show message to user.

Many containers which supports managed-transactions also supports optimistic locking.


Hibernate supports optimistic locking, too.
 
Vinay Singh
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks everyone.
Consider a situation here.
10 results displayed to user.2 users click on same set of data.

Case 1: We don't fetch data from dbase as we have this in session.
Case 2 : we bring the data from dbase and then
a) allow both users to update and then allow only one users record to be saved?
b) allow one user to update and to show other user that record is locked
(In this case we are going explicitly maintain to a lock id in a table, which we update once this record is updated ,what if first user never presses upadate ?)

In case 1 we follow the strategy as said by Olexiy or Deepak.
What is to be done in case 2 ?
Vinay
 
Olexiy Prokhorenko
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think that LOCKing database table in any case could be a good practice. This will not bring anything useful, just additional headach and problems.

So, I suggest you to use versioning or timestamping as mentioned above. (They are the same, as you can understand).

The only thing you can vary, is how your application will act to the fact that some user update record already. You can:
1. "Last submit always wins" (not very good, because you can't inform first user that his/her submission was overwritted)
2. "First submit always wins" (usually used, we just inform last user that record was already updated while he/she was doing modifications, and force to re-edit record)
3. "Merge changes" ("first submit wins" and we will in our code compare changes which were done, and will merge them if possible; otherway will report last user).


I don't really know any other way. May be it exists, but definately not very popular. ;-)

Hope this helps!
 
reply
    Bookmark Topic Watch Topic
  • New Topic