Locking (was Re: refreshing the GUI)

[Roland Roberts]

>>>>> "da" == Derek Atkins <warlord@MIT.EDU> writes:

    da> Locking is a challenging thing.  You can't just depend on the
    da> filestore to lock data; what happens if you have something
    da> like looks like this:

    [...]

    da> What do you do?  Presumably the DB can serialize (lock)
    da> requests, so you don't get intersperced data.  But you need
    da> more than that.  In this particular case, User1 got to the DB
    da> first, so presumably user2 would receive a callback about the
    da> change to obj1. However, User2 already tried to commit the
    da> data..  What's the DB to do?

You need a database that supports "select for update".  At some point
the GUI decides the user is about to modify data and so issues a
"select for update" to obtain a lock on the data.  This limits what
databases you can support.  The second user does the same and blocks
until the first one completes, at which point the second user gets the
newer data.  Note that this may have the disconcerting effect of the
data changing when the user starts to edit it....

roland
-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland@rlenter.com                     76-15 113th Street, Apt 3B
rbroberts@acm.org                          Forest Hills, NY 11375