Very good question on a very difficult topic. This is one of the hardest things in a transactional application. The a-d choices you listed are all possibilities and the one you select depends on your situation/requirements. What does the customer want to happen in this case? This topic is discussed in Martin Fowler's new book Patterns of Enterprise Application Architecture.
> -----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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
