Locking (was Re: refreshing the GUI)

Derek Atkins warlord@MIT.EDU
30 Nov 2000 18:56:17 -0500

Phillip J Shelton <shelton11@dingoblue.net.au> writes:

> I don't see how the locking problem is a CM concern.  I mean that you will
> have to solve the locking problem at the level of storing the new data before
> you need to worry about multilpe GUI's trying to read the file to see what
> needs to be changed. Wouldn't a working multiuser data base have some sort of
> locking solution that we could borrow??

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

User1			DB			User2
   <-- read obj1 -----     ------ read obj1 ----->
 <mod obj1>                                    <mod obj1>
   --- commit obj1 --->
                          <----- commit obj1 -----

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

No, the UI really needs to be involved in the "lock" mechanism:

User1			DB			User2
   <-- read obj1 -----     ------ read obj1 ----->
 <mod obj1>                                    <mod obj1>
   ---- lock obj1 --->
                          <------ lock obj1 -----
   <--- lock ack ----
   --- commit obj1 -->
   <--- commit ack ---
                          ------ obj1 mod ------>    
   --- unlock obj1 -->                            <notify user of change>
   <-- unlock ack ----                            <reconcile obj1 diffs>
                          ------- lock ack ----->
                          <----- commit obj1 ---
                          ------- commit ack --->
                          <--- unlock obj1  ----
                          ----- unlock ack ----->

Obviously there are some coherency problems in this model, too.  You
really want an atomic commit operation, but you also want a check for
coherency as part of the commit.

As I said, it's a challenging problem.  But you can't just write it
off to the DB.  The UI has to be able to allow the user to reconcile a
conflict.  Perhaps this is a problem big enough to be put off until
later.  Hrm..

       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       warlord@MIT.EDU                        PGP key available