By default the last update would win. Ok for small systems. Any system with multiple editors should at the very least have some auditing columns (in the data table or a separate table) like 'creator', 'modifier', etc. The most common solution to concurrent updates is a 'lockedBy' column, to prevent B from getting an edit screen for 007. The main problem with this approach is stale locks when 'A' doesn't properly log out. The least-effort, honor-system way out of that is to enable anyone to break a lock. 'A' might be mad when she hits 'save' and learns that B has stolen the lock, but it's better than dropping her updates completely.
If you don't like the lockedBy column and you are running in only one JVM, you could use a static Hashtable that keeps track of who's got their fingers into what. But you'll still have to deal with stale locks. Anyone out there who has a *general* solution for merging two versions of the same data set is invited to also walk on water and rewrite CVS. :) 'Sending a message' to A or B assumes that you have some push method to contact the user. This could be an applet, or maybe something silly like a 'message' frame that refreshes every 10 seconds. Either way it's a bad hack. The main problem here is that no matter how much we pretend, HTTP is stateless and connectionless. Carlos -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 6:41 AM To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation -> user B has no "update" button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
