Journal

As explained in Akka in Action, Second Edition

A journal is an append-oriented store that preserves events in write order and supports retrieving them in that order.

A journal is an append-only store of events. It preserves an actor’s history in write order and returns that history in the same order. Rather than replacing a single stored state value, a persistent actor records accepted changes as ledger entries. section 1.5.1 section 9.2

A command first expresses an intended change. The actor validates it; if accepted, it produces an event and stores it in the journal. The event history is therefore the durable record used to reconstruct state, while normal application logic can remain message-oriented instead of database-operation-oriented. section 1.5.1 section 9.2

A journal supports two central operations:

• Append each accepted event, retaining the complete history of a persistent actor. section 9.2
• Replay events in stored order after restart to return an actor to its last known state. section 1.5.1 section 9.2
• Expose events for independent readers that build tables, topics, external-service calls, or other views. section 10.0 section 10.2.1

Recovering a conversation

A Conversation actor keeps MessageAdded events for messages added in memory. On a web-server restart, it reads those events back and replays them to rebuild the conversation, then continues processing new messages. The database is used for recovery rather than as the vocabulary of the application’s code. section 1.5.1

Journal data can also serve requirements that were not anticipated when an actor was designed. A stream of AddCargo events can be aggregated by container to maintain total weight in another store. Separating this read-side aggregation from event writing decouples readers from writers and allows the derived data to scale independently. section 10.0 section 10.2.1

Projection-driven settlement

A projection can read Market.Closed events from a market journal. A listener can then find bets for that market and send each bet a Settle message; another projection can store bet and market identifiers for that lookup. The same event history thus supports operational workflows beyond actor recovery. section 12.1.3

Figure 9.6 Persistent actor recovery

The recovery flow visualizes the journal as the durable event history replayed to restore a persistent actor’s state after restart. section 9.2

Figure 10.3 Generic case when reading from the journal

The read-side architecture shows journal events flowing through aggregation and storage into a separate database or topic. section 10.2.1

How Akka in Action, Second Edition covers it

How deep it goes

Defines append-only ledger semantics, traces validation-to-event persistence and replay, and defers serialization details.

Examples

Uses MessageAdded conversations, container-weight aggregation, and betting-market settlement projections.

What it assumes

Introduces journal behavior from message handling and event replay while deferring serialization details.

What you can do after

Apply it via Akka Persistence and persistence queries to recover actors and build read-side views.

How it connects

Connects event sourcing, persistent actors, commands, events, replay, Akka Streams, persistence queries, projections, and sharding.

liveBookmanning.com

Read Akka in Action, Second Edition on liveBook Get the book at manning.com

Related concepts

• Persistence Queryaddressed by · Persistence Query is an Akka Persistence module for querying stored events and other durable representations of persistent actors.
• projectionused by · A projection is a derived, typically read-only representation of selected or transformed domain or event data maintained for querying or a specific purpose.
• recoveryused by · Recovery is the process of restoring access, data, computation, or system operation to an acceptable state after failure, loss, or disruption.
• WiredTigerused by · WiredTiger is MongoDB's storage engine that manages data persistence, caching, and on-disk storage.
• taggingused by · Tagging is the assignment of descriptive labels or metadata to information or resources to support their identification, classification, organization, filtering, or retrieval.

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.