How deeply does Akka in Action, Second Edition cover actor model?

Defines actor operations and asynchronous messaging, but defers detailed runtime implementation mechanics.

Actor model in Akka in Action, Second Edition

The actor model structures concurrent computation as isolated actors that encapsulate state and behavior and communicate through asynchronous messages.

The actor model is a single abstraction for concurrent and distributed applications: actors send and receive messages rather than coordinating through a mix of threads, shared mutable state, and RPC. This decouples application logic from the number of CPUs or servers, so the same programming model can support scaling up and scaling out. section 1.1 section 1.6

An actor is a lightweight process that encapsulates its internal state. Other actors cannot call its methods or directly access that state; they communicate only by sending messages. Messages are sent asynchronously in fire-and-forget style, allowing the sender to continue working. When confirmation matters, the receiver can send an acknowledgment message back. section 1.6.2

Actors have four asynchronous core operations:

Create actors to divide an application into lightweight components. section 1.6.2
Send messages to communicate without sharing mutable state. section 1.6.2
Designate the next behavior as an actor continues processing. section 1.6.2
Supervise actors to organize and handle failing components. section 1.6.2

Chat application components

A chat application can model its components as actors. A Conversation actor sends a message to a Mentions actor instead of calling it directly or sharing a mutable list of conversation messages. The Conversation actor need not wait for the result, which decouples the components; an acknowledgment can provide confirmation when needed. section 1.3 section 1.6.2

Table 1.1 Differences between the traditional approach and the Akka approach (view table figure)

Objective	Traditional method	Akka method
Scaling	Uses a mix of threads, shared mutable state in a database (create, insert, update, delete), and web service RPC calls	Actors send and receive messages. No shared mutable state. Log of immutable events.
Providing interactive information	Polls for current information	Event-driven: pushes when the event occurs
Scaling out on the network	Synchronous RPC, blocking I/O	Asynchronous messaging, nonblocking I/O
Handling failures	Handles all exceptions; continues only if everything works	Lets the application crash. Isolates the failure, and continues without the failing parts.

Compare a thread-, database-, and RPC-based design with message-driven actors. The contrast highlights immutable events, event-driven updates, nonblocking I/O, and failure isolation. section 1.3

The model replaces several scaling concerns with message-driven components: no shared mutable state, event-driven updates rather than polling, and asynchronous messaging rather than synchronous RPC and blocking I/O. Failure handling also favors isolating a failing part so other parts can continue, instead of requiring the entire application to keep working together. section 1.3 section 1.8

Actor-based design does not make every problem easy, but it reduces the complexity of choosing separate constructs for local concurrency and network distribution. It is particularly suited to applications that must evolve from a small deployment toward greater demand while retaining one coherent programming model. section 1.0 section 1.8

How Akka in Action, Second Edition covers it

Also explained in

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Akka in Action, Second Edition. The section links point to the parts of the book it draws on.