I agree with you about the one-for-one mapping.  There will be some
overhead to that scheme, but it will hardly matter when our machines
have thousands of processors.  Also, I would think that such a scheme
would be a highly effective means of managing such hardware.

However, even with a one for one mapping, you still have no guarantees
against failure.  And, you should have a means of recovering from a
failure.  Recovery in this sense means that the system returns to a
state where all constraints are satisfied.  Such a failure could occur
if a message fails to arrive at its destination for example.
Transactions are a very effective means of managing this recovery, but
certainly not the only means...you can do it by hand.

So, to make it concrete, if we return to the bank accounts, we have the
two statements:

bankAccountA withdraw: 500.
bankAccountB deposit: 500.

If the first message is dispatched and successfully completes, but the
second messages fails to reach its target, then the system as a whole
will be in violation of its constraints.  To recover from that we could
either retry the message, or undo the withdrawal.  To do it by hand, we
could do something like: 

bankAccountA withdraw: 500.
[bankAccountB deposit: 500] on: MessageDeliveryFailure do: [ :ex | ex
retry ].

However, what if the message continues to fail?  Then we would need to
fail after some number of retries, then re-deposit the $500 in
bankAccountA.  Now, we have all of this constraint violation testing and
recovery logic embedded into our bankAccount transfer method...this is
certainly not clean or clear.

Using transactions, the logic is simple, it's just:

bankAccountA withdraw: 500.
bankAccountB deposit: 500.

This is clear and to the point.  In fact, you really can't do
distributed systems (a macro level one-for-one mapping if you imaging
each node to be an object) without some sort of distributed transaction
capability...failures in that environment are just too common to be
ingored.

I went and downloaded ToonTalk (very nice BTW) and your example about
the robots, birds and nests became much more clear.  I thought it was
very neat that your example of how you would maintain multiple states
(with the nests) was nearly identical to the way I actually implemented
my transaction system in Squeak.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Ken Kahn
> Sent: Friday, October 26, 2001 2:13 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Lots of concurrency
> 
> 
> Stephen Pair wrote:
> 
> Except when you want to handle two withdrawals from the same 
> account happening concurrently.  You either need a 
> transaction, or you need to fake concurrency (using a 
> critical section for example).
> 
> ------------------------------------
> 
> Or you move to a computation model in which there is a 
> one-to-one mapping of objects and threads. Then you can let 
> any number of withdrawal messages be sent simultaneously. The 
> receiving object is single-threaded and deals with the 
> incoming queued messages one at a time. No need for 
> transacations or critical sections. And none of the deadlock 
> dangers that come from critical sections.
> 
> Best,
> 
> -ken kahn ( www.toontalk.com )