Locking (was Re: refreshing the GUI)

[Phillip J Shelton]

Derek Atkins wrote:

> 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?

Hmm, this is the CVS merge problem isn't it?

> No, the UI really needs to be involved in the "lock" mechanism:
> [snip]
> 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..

Thank you for your time in explaining this.  I am learning just how much I don't
know.

Would something like having user A have the only permissions to change things if
they opened the account first be a usefull first pass. Or is that too simple?

Phill