Merge pull request #18213 from ktoso/wip-doc-persistentsAreRelated-ktoso
=per #18108 document that batch contains the same persistenceId events
This commit is contained in:
commit
0c952a7037
2 changed files with 8 additions and 6 deletions
|
|
@ -18,11 +18,12 @@ interface AsyncWritePlugin {
|
||||||
*
|
*
|
||||||
* The batch is only for performance reasons, i.e. all messages don't have to
|
* 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
|
* be written atomically. Higher throughput can typically be achieved by using
|
||||||
* batch inserts of many records compared inserting records one-by-one, but
|
* batch inserts of many records compared to inserting records one-by-one, but
|
||||||
* this aspect depends on the underlying data store and a journal
|
* this aspect depends on the underlying data store and a journal
|
||||||
* implementation can implement it as efficient as possible with the
|
* implementation can implement it as efficient as possible. Journals should
|
||||||
* assumption that the messages of the batch are unrelated.
|
* aim to persist events in-order for a given `persistenceId` as otherwise in
|
||||||
*
|
* case of a failure, the persistent state may be end up being inconsistent.
|
||||||
|
*
|
||||||
* Each `AtomicWrite` message contains the single `PersistentRepr` that
|
* Each `AtomicWrite` message contains the single `PersistentRepr` that
|
||||||
* corresponds to the event that was passed to the `persist` method of the
|
* corresponds to the event that was passed to the `persist` method of the
|
||||||
* `PersistentActor`, or it contains several `PersistentRepr` that corresponds
|
* `PersistentActor`, or it contains several `PersistentRepr` that corresponds
|
||||||
|
|
|
||||||
|
|
@ -152,9 +152,10 @@ trait AsyncWriteJournal extends Actor with WriteJournalBase with AsyncRecovery {
|
||||||
*
|
*
|
||||||
* The batch is only for performance reasons, i.e. all messages don't have to be written
|
* 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
|
* atomically. Higher throughput can typically be achieved by using batch inserts of many
|
||||||
* records compared inserting records one-by-one, but this aspect depends on the
|
* 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
|
* underlying data store and a journal implementation can implement it as efficient as
|
||||||
* possible with the assumption that the messages of the batch are unrelated.
|
* possible. Journals should aim to persist events in-order for a given `persistenceId`
|
||||||
|
* as otherwise in case of a failure, the persistent state may be end up being inconsistent.
|
||||||
*
|
*
|
||||||
* Each `AtomicWrite` message contains the single `PersistentRepr` that corresponds to
|
* Each `AtomicWrite` message contains the single `PersistentRepr` that corresponds to
|
||||||
* the event that was passed to the `persist` method of the `PersistentActor`, or it
|
* the event that was passed to the `persist` method of the `PersistentActor`, or it
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue