Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Data corruption in multi user web application

 
Jason Mrick
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello. My company currently has a J2EE web app serving about 300 internal employees. Now that the app is being heavily used, we are noticing data corruption by the users. For example...

Step #:
1) User A is served a jsp which contains a form filled with data ready to be updated.
2) User B is served a jsp which contains a form filled with data ready to be updated. This is the same data as User A.
3) User A changes the data, and clicks "Update". The commit is done in Oracle.
4) User B, never seeing User A's change because the jsp was not refreshed, submits their changes (which are different from User A's). This overwrites User A's data with User B's and the first set of changes are lost.


Is there any Oracle/JDBC/Java best practices to resolve this? There must be something since web apps are so popular now....

TIA


 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, this is an old, and quite fundamental, problem with database backed applications (which predates web apps by some considerable time). Your application needs to implement a locking strategy of some sort. Have a google, or search these forums, for "optimistic locking".
 
Jason Mrick
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Sturrock wrote:Yeah, this is an old, and quite fundamental, problem with database backed applications (which predates web apps by some considerable time). Your application needs to implement a locking strategy of some sort. Have a google, or search these forums, for "optimistic locking".


Awsome! I will take a look! Thanks again.
 
Tom Reilly
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or, depending on the frequency of this problem, you can check to see whether the data had been updated before you try to update it and respond with an error if this is the case. For example, you can add a lastUpdateDate (date/time) on the table you are updating. Read this along with the other data (but do not let the user update the field). When you update the data in the database, compare the lastUpdateDate with the one in your database and discontinue the update if they are unequal.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom Reilly wrote:Or, depending on the frequency of this problem, you can check to see whether the data had been updated before you try to update it and respond with an error if this is the case. For example, you can add a lastUpdateDate (date/time) on the table you are updating. Read this along with the other data (but do not let the user update the field). When you update the data in the database, compare the lastUpdateDate with the one in your database and discontinue the update if they are unequal.


No "or" about it - that's optimistic locking.
 
Jason Mrick
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tom Reilly wrote:Or, depending on the frequency of this problem, you can check to see whether the data had been updated before you try to update it and respond with an error if this is the case. For example, you can add a lastUpdateDate (date/time) on the table you are updating. Read this along with the other data (but do not let the user update the field). When you update the data in the database, compare the lastUpdateDate with the one in your database and discontinue the update if they are unequal.


Yeah, this was the approach we came up with so far but wanted to see what other options we had out there.....
 
Tom Reilly
Rancher
Posts: 618
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No "or" about it - that's optimistic locking.
Excellent! Now I know what to call it without running out of breath :-)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic