When should you not use actors?

0. 
   
1. Shared mutable data is the root cause of most of the concurrency problems, and how actors eliminate that using shared nothing architecture. But what if you have to have a shared state across multiple components?
   
    Shared state—A classic example is where you want to transfer money from one account to another, and you want to have a consistent view across the applica- tion. You need more than actors. You need transaction support. Alternatives like STM would be a great fit for this kind of problem, or you have to build transactions over message passing.
   
    Cost of asynchronous programming—For many programmers, it’s a paradigm shift to get used to asynchronous programming. It takes time and effort to get com- fortable if you are not used to it. Debugging and testing large message-oriented applications is hard. At times, asynchronous message passing makes it difficult to track and isolate a problem (knowing the starting point of the message helps). This has nothing to do with the actor model specifically, but more to do with the inherited complexity of messaging-based applications. Lately Akka TestKit and Typesafe console are helping to mitigate the testing and debugging issues.
   
    Performance—If your application has to have the highest performance, then because actors may add an overhead, you may be better off using a much lower level of abstraction, like threads. But again, for 99.9 percent of applications, I think the performance of actors is good enough.
   

Akka no longer includes the STM module but instead supports Scala STM.

Software transactional memory (STM) turns a Java heap into a transactional dataset. STM is similar to database transactions, but is used for memory instead. Because mem- ory isn’t durable with STM, you only get the first three properties of ACID (atomicity, consistency, isolation, durability)

The best part of STM is freedom from locks. It rolls back from exceptions and is com- posable. You can also take two smaller STM operations and combine them to create bigger STM operations.

Reference:

http://nbronson.github.com/scala-stm/.