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.
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
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?
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
Joined: Dec 15, 2004
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
Joined: Jul 11, 2004
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. ;-)