Sorry, I meant in your BankAccount example. I was thinking about some 
kind of switch to make specific Objects begin implicit transactions for 
each message received. This switch could optionally be used in 
conjunction with explicit transactions. The goal being to reduce the 
code changes required.

| bankAccount |
bankAccount := BankAccount new.

" implicit transactions for all methods "
bankAccount shareAll

" implicit transactions for only #transfer:to "
bankAccount share: #transfer:to

" no implicit transactions "
bankAccount shareNone

I greatly prefer the asynch/active model as none of this seems necessary 
(from what I have read so far). As far as I can tell, the developer need 
not do *anything* different to benefit and be protected from
concurrency.

J J wrote:
> But they don't.  Only variables updates (NOTE: most reads don't) do.