Transactors: Actors + STM

Transactors: Actors and STM

Transactors: Actors + STM

Actors are excellent for solving of problems where you have many independent processes 
that can work in isolation and only interact with other Actors through message passing. 
This model fits many problems. But the actor model is unfortunately a terrible model for 
implementing truly shared state. E.g. when you need to have consensus and a stable view of 
state across many components. The classic example is the bank account to clients to 
deposits and withdrawals in which each operation needs to be atomic. For detailed 
discussion on the topic see this JavaOne presentation: 
http://www.slideshare.net/jboner/state-youre-doing-it-wrong-javaone-2009.

STM on the other hand is excellent for problems where you need consensus and a stable 
view of the state by providing compositional transactional shared state. Some of the really 
nice traits of STM is that transactions compose and that it raises the abstraction 
level from lock-based concurrency.

Transactors, e.g. being able to optionally combine Actors and STM provides IMHO the 
best of the Actor model (concurrency and asynchronous event-based programming) and STM 
(compositional transactional shared state) by providing transactional, compositional, 
asynchronous, event-based message flows.