welcome to section four acha persistence
in the previous section we discussed the
difference between actor reference actor
path and actor selection we also
introduced routing in Acker and how to
replace actor behavior via become under
come and FSM now let's start our next
topic in this section we will take a
look at overview on Acker persistence
and architecture we will then implement
a persistent actor and play with it
after that we will look at persistent
FSM and finally we will introduce
persistence query which is a new
experimental module in akka 2.4 let's
start with the introduction to akka
persistence in this video we will take a
look at what's a persistent actor and
what's the difference between a normal
actor and a persistent actor then we
will discuss the architecture of akka
persistence let's start let's imagine we
have an actor that contains a counter
variable which increments after
receiving a message but if this actor
crashes we will lose the internal state
there are many cases where we need to
retain the internal state as well
we need actors that can persist the
internal state when the actor crashes
for some reason we need to make sure his
state is stored at a safe place such as
a database or a file and after the
activist starts it can read the last
persisted state and start from there
a key uses a very similar idea in a
persistence the key concept behind occur
persistence is that only the changes to
an actor's internal state are persisted
but never its current state directly
this means that we don't store the
internal state that we store events from
which the internal state can be
recovered the basic idea behind a cup
assistance is quite simple a persistent
actor receives a new message that calls
a command which is first validated if it
can be applied to the current state if
validation succeeds events are generated
from the command representing the effect
of the command these events are then
persisted and after successful
persistence
used to change the actors state when the
persistent actor needs to be recovered
only the persisted events are replayed
for which we know that can be
successfully applied now let's introduce
the architecture of occur persistence
persistent actor this is a persistent
stateful actor it can persist events to
a journal and can react to them in a
thread safe manner it can also be used
to implement both the command and the
event sourced actors when such an actor
is started or restarted journaled
messages are played to that actor so
that it can recover its internal state
from these messages persistent view it
is a persistent stateful actor that
receives journaled messages that have
been written by another persistent actor
a view itself does not journal new
messages it instead updates the internal
state only from a persistent actors
replicated message stream this is
deprecated from akka 2.4 and we should
use persistence query instead we will
discuss persistence query in detail in
the last video of this section async
write journal a journal that stores a
sequence of events sent to a persistent
actor an application can control which
messages are journaled and which are
received by the persistent actor without
being journaled the storage back-end of
the journal is pluggable the default
journal storage plug-in writes to the
local file system and of course this is
not for production for production akka
recommends cassandra or JDBC back-end
driver snapshots store a snapshot store
persists snapshots of a persistent actor
snapshots are used for optimizing
recovery times the storage back-end of a
snapshot store is pluggable the default
snapshot storage plugin writes to a
local file system you can check the full
documentation for persistence from here
and this is a link for Cassandra Journal
and this one is the jdbc
you