You can use a timestamp rather than a count... more meaningful.
In the current application I'm developing, the user is informed of the
interim update along with the new data.
HTH,
Glenn
Lee Harrington <[EMAIL PROTECTED]>
07/02/2005 11:08 AM
Please respond to "Struts Users Mailing List"
To: Struts Users Mailing List <user@struts.apache.org>
cc: (bcc: Glenn Deschenes/NAT/CMHC-SCHL/CA)
Subject: OT: Handling concurrency issues with web apps
Classification:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
