-ProcessorFailureExample.java
-shows how a processor can delete persistent messages from the journal if they threw an exception. Throwing an exception
-restarts the processor and replays messages. In order to prevent that the message that caused the exception is replayed,
-it is marked as deleted in the journal (during invocation of preRestart). This is a common pattern in
-command-sourcing to compensate write-ahead logging of messages.
+In a command sourced system you may persist the commands to the journal immediately. However this might cause problems
+in the case where you persist a command that corrupts your state. The corrupt command will be replayed again whenever you recover your state and you would have
+to delete the corrupt commands from the journal.
-To run this example, go to the Run tab, and run the application main class
-sample.persistence.ProcessorFailureExample several times.
-
-Event sourcing -on the other hand, does not persist commands directly but rather events that have been derived from received commands +In an event sourced +system, one does not persist commands directly but rather events that have been derived from received commands (not shown here). These events are known to be successfully applicable to current processor state i.e. there's no need for deleting them from the journal. Event sourced processors usually have a lower throughput than command sourced processors, as the maximum size of a write batch is limited by the number of persisted events per received