GUID Management

Derek Atkins warlord@MIT.EDU
04 Jan 2001 09:52:37 -0500


Christopher Browne <cbbrowne@smtp.hex.net> writes:

> I think it needs more than just a version number.
> 
> Suppose two independent updates try to take place "concurrently."
> 
> One goes in, as "version 4," and another goes in, also proposed as
> "version 4."  If all that is tracked is the version number, then
> the second update gets silently ignored.  Bad Thing.

No, it doesn't get silently ignored; the user gets a "stale data"
response which informs them that their transaction was edited from
under them.  Then the user can decide what to do about it, after they
"refresh" their data (granted, hopefully there would be an event that
notifies the client of the data change).

> Given time/session stamps, we can make up meaningful policies of "how
> to cope," probably reporting back to "session dcbrowne:567" something
> to the effect that "someone else was updating that record;" try
> again...

You can do that without the time/session stamps; as I've said, you can
do that with a version number just as easily.  Also, not that we _do_
have update timestamps and update users in the structures, so we do
know who updated an object, and when.  However that's not at all
necessary to know that you have a conflict.

-derek

-- 
       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-IA     N1NWH
       warlord@MIT.EDU                        PGP key available