- This topic has 1 reply, 2 voices, and was last updated 19 years, 2 months ago by
.
-
Posts
-
Ok…here’s a general development issue that conerns any web based app that is data entry oriented. I’ve been doing reporting systems so long, I’ve gotten a bit rusty with transactional development.
What’s the best strategy for avoiding “last save wins” concurrency issues? If two people open a web maintenance page, change data, and save, the “last saved” wins, meaning the person who saved first loses their changes.
In the client server world, we’d simply lock the record when someone opened the screen….but you can’t do that in a stateless web environment. How would you know the client logged off (or simply closed their browser)? The record could remain locked forever….not to mention you are using shared connections and only the “app server” has an account with the database.
Right now I have a plan for keeping a field with a “count”…that gets incremented when someone saves a change. But before a save occurs, the count is checked, and if it’s not the same as when you opened the page, that means someone else has saved in the mean time, and you can inform the user that they need to refresh, and remake their changes.
Any better plan than this?
Lee
Lee,
I think your solution is elegant and simple. Bugzilla has implemented something like this for quite a while… I’m not privvy to the implementation details of it, but it is just how you describe “Oops, there is a conflict. Someone has changed this same record, if you wish to overwrite their changes say Yes, otherwise refresh your page” ssomething to that extent.
