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.

> You could write a transfer method, but even that
> method could leave the system in an invalid state were it to fail in
> just the right spot.  So, basically, what you need is a way to
> capture multiple changes in state and apply all or none of those
> changes in an atomic fashion.

You need an object that actually implements 'globalBalance' and takes 
care of it. There might be software failures (the #withdraw: might not 
execute due to lack of funds and then the total result would be wrong) 
or there might be a hardware failure. It becomes harder to build this 
imaginary object, however, in the case where the #withdraw: and 
#deposit: will be executed on different computers.

> This is exactly what Kats (http://spair.swiki.net/kats) is designed
> to do.  Just write:
>
> tx := TxTransaction new.
> [
>    bankAccountA withdraw: 500.
>    bankAccountB deposit: 500.
> ] valueInTransaction: tx.
> tx commit.

Good job! The tx object is what I was talking about above. A "real" 
object wouldn't work, of course, but tx is actually a meta-object which 
is exactly what is needed in this case. It implements what was just an 
abstract state by doing implementation level manipulation of parts of 
the states of multiple objects.

> Currently, Kats needs methods to be compiled with the transactional
> compiler in order to get this behavior.  Ian Piumarta gave me some
> good ideas at OOPSLA about how to provide generic VM support such
> that any object can be subject to transactional control without
> negatively impacting the normal (non-transactional) operation of
> Squeak.  That would be neat.

Yes it would. Even better would be a CoDA style reflective layer in the 
VM where this sort of thing could be added with 100% Squeak code.

> (note: this thread on concurrency is discussing a couple different
> ideas under the "concurrency" label, state changes governed by
> transactions is different from the multi-processing ideas that have
> also been termed concurrency...one deals with issues of controlling
> state transition in ways that can detect conflict and preserve
> consistency at all times, the other deals event mechanisms,
> asynchronous messaging, concurrent processing and such)

I think this is actually good - by considering these different, but 
related, ideas together we might come up with a design that can "kill 
two birds with one stone".

-- Jecel