public interface AsyncWriteJournal extends Actor, WriteJournalBase, AsyncRecovery
|Modifier and Type||Interface and Description|
|Modifier and Type||Method and Description|
Plugin API: asynchronously deletes all persistent messages up to
Plugin API: asynchronously writes a batch (
Scala API: This defines the initial actor behavior, it must return a partial function with the actor logic.
akka$actor$Actor$_setter_$context_$eq, akka$actor$Actor$_setter_$self_$eq, aroundPostRestart, aroundPostStop, aroundPreRestart, aroundPreStart, aroundReceive, context, postRestart, postStop, preRestart, preStart, self, sender, supervisorStrategy, unhandled
adaptFromJournal, adaptToJournal, akka$persistence$journal$WriteJournalBase$_setter_$persistence_$eq, persistence, preparePersistentBatch
void akka$persistence$journal$AsyncWriteJournal$_setter_$receiveWriteJournal_$eq(scala.PartialFunction<java.lang.Object,scala.runtime.BoxedUnit> x$1)
void resequencerCounter_$eq(long x$1)
scala.concurrent.Future<scala.collection.immutable.Seq<scala.util.Try<scala.runtime.BoxedUnit>>> asyncWriteMessages(scala.collection.immutable.Seq<AtomicWrite> messages)
Seq) of persistent messages to the journal.
The batch is only for performance reasons, i.e. all messages don't have to be written
atomically. Higher throughput can typically be achieved by using batch inserts of many
records compared to inserting records one-by-one, but this aspect depends on the
underlying data store and a journal implementation can implement it as efficient as
possible. Journals should aim to persist events in-order for a given
as otherwise in case of a failure, the persistent state may be end up being inconsistent.
AtomicWrite message contains the single
PersistentRepr that corresponds to
the event that was passed to the
persist method of the
PersistentActor, or it
PersistentRepr that corresponds to the events that were passed
persistAll method of the
PersistentRepr of the
AtomicWrite must be written to the data store atomically, i.e. all or none must
be stored. If the journal (data store) cannot support atomic writes of multiple
events it should reject such writes with a
Failure with an
UnsupportedOperationException describing the issue. This limitation should
also be documented by the journal plugin.
If there are failures when storing any of the messages in the batch the returned
Future must be completed with failure. The
Future must only be completed with
success when all messages in the batch have been confirmed to be stored successfully,
i.e. they will be readable, and visible, in a subsequent replay. If there is
uncertainty about if the messages were stored or not the
Future must be completed
Data store connection problems must be signaled by completing the
The journal can also signal that it rejects individual messages (
immutable.Seq[Try[Unit}. It is possible but not mandatory to reduce
number of allocations by returning
Future.successful(Nil) for the happy path,
i.e. when no messages are rejected. Otherwise the returned
Seq must have as many elements
as the input
Try element signals if the corresponding
AtomicWrite is rejected or not, with an exception describing the problem. Rejecting
a message means it was not stored, i.e. it must not be included in a later replay.
Rejecting a message is typically done before attempting to store it, e.g. because of
Data store connection problems must not be signaled as rejections.
It is possible but not mandatory to reduce number of allocations by returning
Future.successful(Nil) for the happy path, i.e. when no messages are rejected.
Calls to this method are serialized by the enclosing journal actor. If you spawn work in asynchronous tasks it is alright that they complete the futures in any order, but the actual writes for a specific persistenceId should be serialized to avoid issues such as events of a later write are visible to consumers (query side, or replay) before the events of an earlier write are visible. A PersistentActor will not send a new WriteMessages request before the previous one has been completed.
Please note that the
sender field of the contained PersistentRepr objects has been
nulled out (i.e. set to
ActorRef.noSender) in order to not use space in the journal
for a sender reference that will likely be obsolete during replay.
Please also note that requests for the highest sequence number may be made concurrently
to this call executing for the same
persistenceId, in particular it is possible that
a restarting actor tries to recover before its outstanding writes have completed. In
the latter case it is highly desirable to defer reading the highest sequence number
until all outstanding writes have completed, otherwise the PersistentActor may reuse
This call is protected with a circuit-breaker.
scala.concurrent.Future<scala.runtime.BoxedUnit> asyncDeleteMessagesTo(java.lang.String persistenceId, long toSequenceNr)
This call is protected with a circuit-breaker. Message deletion doesn't affect the highest sequence number of messages, journal must maintain the highest sequence number and never decrease it.
Allows plugin implementers to use
f pipeTo self and
handle additional messages for implementing advanced features