At Sat, 22 Dec 2001 06:55:15 -0800 (PST) , brian moseley <[EMAIL PROTECTED]> wrote: >if locking is necessary in some instances, even if we can >only contrive theoretical examples right now, how might it >be done in a performant way, especially for objects that can >be modified multiple times while handling a single request?
I see two basic ways the locking can be done. One is to create a get_for_update() method that holds an exclusive lock. You could still call get() for read-only access, but you would not automatically pick up changes from other processes and thus should not write any data that you read with a get(). This is dependent on people being careful to always call get_for_update() if they intend to update data. There is no extra serialization, and you could do record-level locking with most storage backends. The other way is to do optimistic locking with version numbers and throw an exception if someone else has updated the record you want to update. This is only useful for a certain class of apps, like data entry screens where collisions are rare and you can just tell the user to look at the new data and enter her changes again. - Perrin
