Re: Commitment control (was: framework question)

["Buck Calabro" <buck.calabro@xxxxxxxxxxxx>]

Hi Joe!

> This is the crux of my argument, in fact.  Any
> set of related records that need to be updated
> ought to have a single record that is at their root.
> Now this may not always be the case; let's leave
> that case, shall we?

I wish we could leave that case, alas there is the simple enough fact
that many of us have to deal with code touched by many hands, evolving
over many years without any actual design work being done (or
recorded) and with updates being done in many, many places.  Given
this 'accidental architecture', commitment control is often the
easiest way to keep one's sanity.  It isn't easy to retrofit an
existing application to use the 'lock one master record' model when
updates happen in many places.
  --buck