The base type of PersistentEntity events may implement this interface to make the events available for read-side processing.
The base type of PersistentEntity events may return one of these to make the events available for sharded read-side processing.
The base type of PersistentEntity events may return one of these to make the events available for read-side processing.
The base type of PersistentEntity events may return one of these to make the events available for read-side processing.
The tag
should be unique among the event types of the service.
The class name can be used as tag
, but note that it is needed
to retain the original tag when the class name is changed because
the tag is part of the store event data.
Selects a tag for an event.
Selects a tag for an event.
Can either be a static tag, or a sharded tag generator.
Commands to PersistentEntity are wrapped in this envelope when sent via PersistentEntityRef (i.e.
Commands to PersistentEntity are wrapped in this envelope when sent via PersistentEntityRef (i.e. Cluster Sharding).
Users should normally not use this class, but it is public case for power users in case of integration with Cluster Sharding entities that are not implemented with PersistentEntity.
Envelope for events in the eventstream, provides additional data to the actual event
Persistence components (for compile-time injection).
A PersistentEntity
has a stable entity identifier, with which
it can be accessed from anywhere in the cluster.
A PersistentEntity
has a stable entity identifier, with which
it can be accessed from anywhere in the cluster. It is run by an actor
and the state is persistent using event sourcing.
initialState
and behavior
are abstract methods that your concrete subclass must implement.
The behavior is defined as a set of actions given a state. The actions are functions to process
incoming commands and persisted events.
The PersistentEntity
receives commands of type Command
that can be validated before
persisting state changes as events of type Event
. The functions that process incoming
commands are registered in the Actions
using onCommand
of the
Actions
.
A command may also be read-only and only perform some side-effect, such as replying
to the request. Such command handlers are registered using onReadOnlyCommand
of the Actions
. Replies are sent with the reply
method of the context that
is passed to the command handler function.
A command handler returns a Persist
directive that defines what event or events,
if any, to persist. Use the thenPersist
, thenPersistAll
or done
methods of the
context that is passed to the command handler function to create the Persist
directive.
When an event has been persisted successfully the state of type State
is updated by
applying the event to the current state. The functions for updating the state are
registered with the onEvent
method of the Actions
.
The event handler returns the new state. The state must be immutable, so you return
a new instance of the state. Current state is passed as parameter to the event handler.
The same event handlers are also used when the entity is started up to recover its
state from the stored events.
After persisting an event, external side effects can be performed in the afterPersist
function that can be defined when creating the Persist
directive.
A typical side effect is to reply to the request to confirm that it was performed
successfully. Replies are sent with the reply
method of the context that is passed
to the command handler function.
The event handlers are typically only updating the state, but they may also change the behavior of the entity in the sense that new functions for processing commands and events may be defined for a given state. This is useful when implementing finite state machine (FSM) like entities.
When the entity is started the state is recovered by replaying stored events. To reduce this recovery time the entity may start the recovery from a snapshot of the state and then only replaying the events that were stored after the snapshot. Such snapshots are automatically saved after a configured number of persisted events.
Commands are sent to a PersistentEntity using a
PersistentEntityRef
.
Commands are sent to a PersistentEntity using a
PersistentEntityRef
. It is retrieved with PersistentEntityRegistry#refFor.
At system startup all PersistentEntity classes must be registered here with PersistentEntityRegistry#register.
At system startup all PersistentEntity classes must be registered here with PersistentEntityRegistry#register.
Later, com.lightbend.lagom.scaladsl.persistence.PersistentEntityRef can be
retrieved with PersistentEntityRegistry#refFor.
Commands are sent to a com.lightbend.lagom.scaladsl.persistence.PersistentEntity
using a PersistentEntityRef
.
The Lagom read-side registry.
The Lagom read-side registry.
Handles the management of read-sides.
Read-side persistence components (for compile-time injection).
A read side processor.
A read side processor.
Read side processors consume events produced by com.lightbend.lagom.scaladsl.persistence.PersistentEntity instances, and update some read side data store that is optimized for queries.
The events they consume must be tagged, and a read side is able to consume events of one or more tags. Events are
usually tagged according to some supertype of event, for example, events may be tagged as Order
events.
They may also be tagged according to a hash of the ID of the entity associated with the event - this allows read
side event handling to be sharded across many nodes. Tagging is done using
com.lightbend.lagom.scaladsl.persistence.AggregateEventTag.
Read side processors are responsible for tracking what events they have already seen. This is done using offsets, which are sequential values associated with each event. Note that end users typically will not need to handle offsets themselves, this will be provided by Lagom support specific to the read side datastore, and end users can just focus on handling the events themselves.
Write-side persistence components (for compile-time injection).
The base type of PersistentEntity events may return one of these to make the events available for sharded read-side processing.
The
tag
should be unique among the event types of the service.The
numShards
should be stable and never change.The class name can be used as
tag
, but note that it is needed to retain the original tag when the class name is changed because the tag is part of the store event data.