Jecel wrote:
> And the problem can't really be solved with better designs - only 
> pushed up into higher levels. If we eliminate #setBalance: and force 
> clients to go through #changeBalanceBy: instead (or #deposit: and 
> #withdraw:) we will still have the case where a client will check the 
> balance, make a decision to withdraw and then not have enough 
> funds by 
> the time it gets around to doing it. As I said, going to a 
> higher level 
> as with #checkFundsAndWithdraw: helps a lot but doesn't totally solve 
> the problem.
> 
> Even #changeBalanceBy: runs into a state replication problem: the 
> execution stack. If multiple threads are allowed inside the objects 
> then we have multiple stacks and state goes from the instance 
> variables 
> to each of these stacks where it is actually changed and then 
> goes back 
> to the instance variables.

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.  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.

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.

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.

(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)

- Stephen