Journal plugin

The journal plugin enables storing and loading events for event sourced persistent actors.

Schema

The event_journal table and event_journal_slice_idx index need to be created in the configured database, see schema definition in Creating the schema.

The event_journal_slice_idx index is only needed if the slice based queries are used.

Relation to Pekko JDBC plugin

Pekko Persistence R2DBC plugin tables are not compatible with the tables of Pekko Persistence JDBC. JDBC data must be migrated using the migration tool and a different schema/database must be used (or the table names overridden).

Configuration

To enable the journal plugin to be used by default, add the following line to your Pekko application.conf:

pekko.persistence.journal.plugin = "pekko.persistence.r2dbc.journal"

It can also be enabled with the journalPluginId for a specific EventSourcedBehavior and multiple plugin configurations are supported.

See also Connection configuration.

Reference configuration

The following can be overridden in your application.conf for the journal specific settings:

sourcepekko.persistence.r2dbc {
  journal {
    class = "org.apache.pekko.persistence.r2dbc.journal.R2dbcJournal"

    # name of the table to use for events
    table = "event_journal"

    # Otherwise it would be a pinned dispatcher, see https://github.com/akka/akka/issues/31058
    plugin-dispatcher = "pekko.actor.default-dispatcher"

    # event replay is using pekko.persistence.r2dbc.query.buffer-size

    # Enable this to reduce latency of eventsBySlices. The persisted events will be
    # published as Pekko messages and consumed directly by running eventsBySlices
    # queries. Tradeoff is more CPU and network resources that are used. The events
    # must still be retrieved from the database, but at a lower polling frequency,
    # because delivery of published messages are not guaranteed.
    publish-events = off

    # replay filter not needed for this plugin
    replay-filter.mode = off
  }
}

Deletes

The journal supports deletes through hard deletes, which means the journal entries are actually deleted from the database. There is no materialized view with a copy of the event so make sure to not delete events too early if they are used from projections or queries.

1.0.0