Akka Persistence Module

Pros:

• Completely Asynchronous, no blocks
• Reliable
• Scalable
• Failover

Cons:

• Experimental Module,
• no commercial support,
• API may break in near future.

(1) What to persist?

Only changes to an actor’s internal state are persisted but never its current state directly.
When the persistent actor needs to be recovered, only the persisted events are replayed.

(2) Persist in journal or snapshot

Journal:

• A journal stores the sequence of messages sent to a persistent actor.
• Journal is used instead of log
• Appending only, without updates
• Support batch writes to optimize throughput.

Snapshots: are used for optimizing recovery times.

(3) Default use case 

The events are persisted and, after successful persistence, used to change the actor’s state.

The persist method persists events asynchronously and the event handler is executed for successfully persisted events.

(4) Relaxed consistency and high throughput use case.

persistAsync() method eventually persist events and handled properly in the background and retroactively reacting to persistence failures if needed. 

The passed in event will be kept in memory and used when invoking the handler.

(5) Storage backends for journals and snapshot stores are pluggable

The default journal/snapshot storage plugin writes to the local filesystem, replicated journals are available as Community plugins,

e.g. Cassandra, HBase, postgreSQL, etc.

The plugin is easy to use. For example, add below lines in application.conf

akka.persistence.journal.plugin = "cassandra-journal"

akka.persistence.snapshot-store.plugin = "cassandra-snapshot-store"

Persist/Store data permanently in disk

This one is different with the above section, instead persisting app data permanently in data stores for analytics, etc.

The data stores can be Cassandra, HBase, ProgreSQL, etc.

The main idea is to implement below 2 actors extending from Actor, respectively

• WriteActor: connect to data store; call customized save() in receive() 
• ReadActor: connect to data store; call customized find() in receive() 

Is reliable message delivery possible?

At-Least-Once Delivery takes care of re-sending messages when they have not been confirmed within a configurable timeout. 

It also implies that original messages end order is not always preserved and the destination may receive duplicate messages.
 

Correlation between deliver and confirmDelivery is performed with the deliveryId. 

The deliveryId is typically passed in the message to the destination, which replies with a message containing the same deliveryId.

Reference:
1. Martin Krasser's Blog
http://krasserm.blogspot.ca/2013/12/introduction-to-akka-persistence.html
2. Distributed transaction discussion
http://qnalist.com/questions/5586312/distributed-transactions-in-akka
3. Akka Transactions and Persistence(Jun, 2010)

http://qnalist.com/questions/5613270/transactions-and-persistence

4. Persistence to Cassandra

https://github.com/krasserm/akka-persistence-cassandra/

5. Official doc 

http://doc.akka.io/docs/akka/2.3.9/scala/persistence.html
6. Sample Code
https://github.com/akka/akka/tree/master/akka-samples/akka-sample-persistence-scala
7. Persist App Data in datastore
https://github.com/eigengo/activator-akka-cassandra