Lots of concurrency

Stephen Pair spair at advantive.com
Thu Oct 25 15:32:09 UTC 2001


Jecel Assumpcao Jr wrote:
> On Wednesday 24 October 2001 14:19, Stephen Pair wrote:
> > Jecel wrote:
> > > [state replication is the problem]
> >
> > The basic problem is that you want to have:
> >
> > bankAccountA withdraw: 500.
> > bankAccountB deposit: 500.
> >
> > execute with all of the ACID properties.  You never want 
> the system to 
> > be in the intermediate state where 500 dollars has been 
> withdrawn, but 
> > not deposited.
> 
> This is a case of distributed state rather than replicated 
> state. There 
> is some abstract state (we can call it 'globalBalance') which isn't 
> inside any particular object.

That's an interesting point of view that I hadn't thought of.  I had
thought of it in terms of a constraint (the sum of all bank accounts
must remain constant).  There are other situations where I think the
constraint point of view works better, but it's really the same idea as
distributed state I think.

In any situation where you have a set of constraints that shouldn't be
violated and involve a number of objects, a transactional system will
allow you to move the system from one consistent state to another in a
controlled fashion.  Writing code so that such constraints can never be
violated would be a heavy burden and lead to very obscure looking code.
In essence, you would be doing what the transaction system does, only by
hand.

- Stephen





More information about the Squeak-dev mailing list