Jose, Perhaps this is where using Transactions would come in - use a begin and end transaction action to ensure that the changes will be committed to the db only if the entire process occurs without error.
Jason On 6/10/02 2:59 PM, "Jose Kuhn" <[EMAIL PROTECTED]> wrote: > While looking through the Web Application and Construction Kit, they had a > section on Row locking while trying to update a value. They assign to the > locked column a 1 to lock it. Only one problem, isn't it theoretically > possible that some one else could be doing a "Locking" update on the same > row. > > Ex > > User1: Search => Finds row 10 unlocked > User2: Search => Finds row 10 unlocked > User1: Since Row 10 unlocked lock row 10 By updated the locked column to 1 > on the Locked row > User2: Since Row 10 unlocked lock row 10 By updated the locked column to 1 > on the Locked row > > When we move to the more robust and multithreaded Witango 5 the above > locking scheme may not work. Wouldn't it be better to use the > <@USEREFERENCE> to truly lock the Row? > This way when the final update is done it is compared with the > <@USERREFERENCE> since it is unique? > > Any Ideas? > > Jose -- ____________________________________________________________________ Jason Pamental, President [EMAIL PROTECTED] Bathysphere Digital Media Services, Inc. http://bathyspheredms.com ____________________________________________________________________ Tel: 401.490.6830 Fax: 401.490.6831 ________________________________________ ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
