Mark van Gulik made a great post about the needed aspects of a 
transactional system (Atomicity, Consistency, Isolation, and 
Durability). Here is how silly you (I, at least) can get when thinking 
about these issues:

   http://www.merlintec.com:8080/software/9

The real problem isn't state, but state "leakage" leading to state 
replication. The balance might be safe inside the account object, but 
once it answers the #getBalance message there is a rogue copy loose in 
the system. Unfortunately, most practical object systems depend of this 
kind of information flow to work.

Things get really nasty if you allow state to "leak back" into the 
object. That is why #setBalance: is so evil. We let the internal state 
escape into the system, be changed in uncontrolled ways and now are 
letting it back in? That is bad OO design. In fact, it is stepping back 
to the low level "assignment based programming" Smalltalk was created 
to save us from in the first place. But it happens all the time and I 
have been no less guilty of it than anyone else.

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.

Ken Kahn and Alan Kay talked about "concurrency at the bottom" as a 
result of the "decompose a computer into smaller computers" definition 
of OOP. Each object would have data, instructions, communications *and* 
a processor. Mario Tokoro wrote lots of good stuff about this and I 
won't repeat him here:

   http://www.mt.cs.keio.ac.jp/techpaper.html

By giving each object its own processor, but only one, the stack state 
replication is no longer a problem. Though I didn't get very far, my 
initial results in this direction were very interesting. It is amazing 
how many objects can be active at the same time even when evaluating a 
simple expression like (2 at 3)+(4 at 5)+(6 at 7).

   http://www.lsi.usp.br/~jecel/tiny.html

Perhaps the problem I was trying to solve (allowing correct concurrent 
execution of legacy sequential code) just isn't worth it and it would 
be better to start from scratch like Ken did in ToonTalk.

While I don't think lots of URLs quoting myself were what Justin Walsh 
had in mind, here goes another one for those with a really wierd sense 
of humor:

   http://www.lsi.usp.br/~jecel/stories/deadlocks.html

-- Jecel