raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

Merge pull request #18213 from ktoso/wip-doc-persistentsAreRelated-ktoso

Browse source 
=per #18108 document that batch contains the same persistenceId events
This commit is contained in:
Konrad Malawski 2015-08-14 13:20:17 +02:00
commit 0c952a7037
2 changed files with 8 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

7
akka-persistence/src/main/java/akka/persistence/journal/japi/AsyncWritePlugin.java
View file

@ -18,10 +18,11 @@ interface AsyncWritePlugin {
*
* 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 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
* implementation can implement it as efficient as possible with the
* assumption that the messages of the batch are unrelated.
* implementation can implement it as efficient as 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 the event that was passed to the `persist` method of the

5
akka-persistence/src/main/scala/akka/persistence/journal/AsyncWriteJournal.scala
View file

@ -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
* 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
* 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
* the event that was passed to the `persist` method of the `PersistentActor`, or it