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
|