This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Lost Update/Concurrency issues in web application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Lost Update/Concurrency issues in web application" Watch "Lost Update/Concurrency issues in web application" New topic
Author

Lost Update/Concurrency issues in web application

Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
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


Technical quiz and interview questions   SCJP 6 mock practice test
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
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 !!!
Vagner Freitas
Ranch Hand

Joined: Aug 02, 2004
Posts: 85
Hi,

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

Vagner


SCJA, SCJP, SCBCD & SCEA (Part I)
Vaithiya Sundaram
Ranch Hand

Joined: Apr 22, 2004
Posts: 98
EJB - Entity Bean CMP automatically supports the above situation.


Vaithiyanathan Sundaram<br />SCJP, SCBCD, SCEA part1
Olexiy Prokhorenko
Ranch Hand

Joined: Jul 11, 2004
Posts: 97
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.


<a href="http://www.BossTalks.com" target="_blank" rel="nofollow">http://www.BossTalks.com</a><br />Free advices and help for entrepreneurs: from Idea to IPO<br />Software and IT Project Management forum
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
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

Joined: Jul 11, 2004
Posts: 97
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!
 
Consider Paul's rocket mass heater.
 
subject: Lost Update/Concurrency issues in web application
 
Similar Threads
Why an IDE?
Trouble with model for calculating and adding table values dependent on multiple rows
Transactions and Threading
Connection and Commit problems between Oracle and Java
HTML form returns entity key -- what's best practice?