• 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

Controling the Web Page

 
Ranch Hand
Posts: 2206
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My web app is used by multiple users accessing the same data base. It is an Engineering application used to control and route changes to Engineering Drawings. There is a page that displays the current state of the drawing which includes buttons to initiate a change. I am concerned that two users may access the same drawing number(which is fine if they just view it). But suppose they both access it then one user makes a change(which will set a lock flag field). The other user has got busy but later desides to make a change to the drawing number they have pulled up on the screen. Since this data has not been refreshed it will not know there is a lock on it now.

How can I fix this so it does not happen? Do I put a timer on the page to force the user to do a refresh on the data? If so how do I do it?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's common to put a timestamp for each update on the database. The user gets the timestamp (maybe in a hidden field) when they retrieve the record. If it doesn't match the database when they want to update the record, that means somebody else beat them to the update. The system says something like "Another user has changed this record. Please refresh it and see what it looks like." The user usually has to discard his changes, get the fresh record and start over. That's "optimistic" locking, meaning we don't think bad things will happen very often and we can stand the pain if they do. It's also called "first update wins" some times.

For "pessimistic" locking where we think this kind of problem is frequent enough that we want to avoid it, we might update the record with a "locked by userid" column when a user retrieves it for update. Then nobody else can retrieve it for update until he does an update or unlock to unset the "locked by" column. You have to make the user declare his intention to update. And the user might turn off the PC and walk away, leaving the record locked forever.

Any of those choices sound good?
[ August 20, 2007: Message edited by: Stan James ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As an aside, Martin Fowler's book "Patterns of Enterprise Application Architecture" has some quite good chapters on this topic.
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
moving to intermediate
 
Life just hasn't been the same since the volcano erupted and now the air is full of tiny ads.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic