1
00:00:04,819 --> 00:00:08,099
welcome to section four acha persistence

2
00:00:08,099 --> 00:00:11,128
in the previous section we discussed the

3
00:00:11,128 --> 00:00:13,320
difference between actor reference actor

4
00:00:13,320 --> 00:00:15,990
path and actor selection we also

5
00:00:15,990 --> 00:00:18,329
introduced routing in Acker and how to

6
00:00:18,329 --> 00:00:21,179
replace actor behavior via become under

7
00:00:21,179 --> 00:00:24,539
come and FSM now let's start our next

8
00:00:24,539 --> 00:00:27,359
topic in this section we will take a

9
00:00:27,359 --> 00:00:30,689
look at overview on Acker persistence

10
00:00:30,689 --> 00:00:33,570
and architecture we will then implement

11
00:00:33,570 --> 00:00:35,340
a persistent actor and play with it

12
00:00:35,340 --> 00:00:37,920
after that we will look at persistent

13
00:00:37,920 --> 00:00:40,890
FSM and finally we will introduce

14
00:00:40,890 --> 00:00:42,960
persistence query which is a new

15
00:00:42,960 --> 00:00:47,670
experimental module in akka 2.4 let's

16
00:00:47,670 --> 00:00:49,320
start with the introduction to akka

17
00:00:49,320 --> 00:00:52,948
persistence in this video we will take a

18
00:00:52,948 --> 00:00:55,829
look at what's a persistent actor and

19
00:00:55,829 --> 00:00:57,689
what's the difference between a normal

20
00:00:57,689 --> 00:01:00,929
actor and a persistent actor then we

21
00:01:00,929 --> 00:01:02,728
will discuss the architecture of akka

22
00:01:02,728 --> 00:01:06,689
persistence let's start let's imagine we

23
00:01:06,689 --> 00:01:08,549
have an actor that contains a counter

24
00:01:08,549 --> 00:01:10,319
variable which increments after

25
00:01:10,319 --> 00:01:12,900
receiving a message but if this actor

26
00:01:12,900 --> 00:01:15,230
crashes we will lose the internal state

27
00:01:15,230 --> 00:01:17,519
there are many cases where we need to

28
00:01:17,519 --> 00:01:19,500
retain the internal state as well

29
00:01:19,500 --> 00:01:21,569
we need actors that can persist the

30
00:01:21,569 --> 00:01:25,109
internal state when the actor crashes

31
00:01:25,109 --> 00:01:27,209
for some reason we need to make sure his

32
00:01:27,209 --> 00:01:29,430
state is stored at a safe place such as

33
00:01:29,430 --> 00:01:31,769
a database or a file and after the

34
00:01:31,769 --> 00:01:33,780
activist starts it can read the last

35
00:01:33,780 --> 00:01:36,090
persisted state and start from there

36
00:01:36,090 --> 00:01:39,060
a key uses a very similar idea in a

37
00:01:39,060 --> 00:01:42,090
persistence the key concept behind occur

38
00:01:42,090 --> 00:01:44,640
persistence is that only the changes to

39
00:01:44,640 --> 00:01:46,709
an actor's internal state are persisted

40
00:01:46,709 --> 00:01:48,859
but never its current state directly

41
00:01:48,859 --> 00:01:51,120
this means that we don't store the

42
00:01:51,120 --> 00:01:53,370
internal state that we store events from

43
00:01:53,370 --> 00:01:54,959
which the internal state can be

44
00:01:54,959 --> 00:01:58,319
recovered the basic idea behind a cup

45
00:01:58,319 --> 00:02:00,930
assistance is quite simple a persistent

46
00:02:00,930 --> 00:02:03,030
actor receives a new message that calls

47
00:02:03,030 --> 00:02:05,370
a command which is first validated if it

48
00:02:05,370 --> 00:02:07,859
can be applied to the current state if

49
00:02:07,859 --> 00:02:10,560
validation succeeds events are generated

50
00:02:10,560 --> 00:02:12,718
from the command representing the effect

51
00:02:12,718 --> 00:02:14,908
of the command these events are then

52
00:02:14,908 --> 00:02:16,829
persisted and after successful

53
00:02:16,829 --> 00:02:17,620
persistence

54
00:02:17,620 --> 00:02:20,199
used to change the actors state when the

55
00:02:20,199 --> 00:02:22,090
persistent actor needs to be recovered

56
00:02:22,090 --> 00:02:24,370
only the persisted events are replayed

57
00:02:24,370 --> 00:02:25,780
for which we know that can be

58
00:02:25,780 --> 00:02:29,229
successfully applied now let's introduce

59
00:02:29,229 --> 00:02:31,830
the architecture of occur persistence

60
00:02:31,830 --> 00:02:34,750
persistent actor this is a persistent

61
00:02:34,750 --> 00:02:37,870
stateful actor it can persist events to

62
00:02:37,870 --> 00:02:39,908
a journal and can react to them in a

63
00:02:39,908 --> 00:02:42,400
thread safe manner it can also be used

64
00:02:42,400 --> 00:02:44,560
to implement both the command and the

65
00:02:44,560 --> 00:02:47,500
event sourced actors when such an actor

66
00:02:47,500 --> 00:02:49,628
is started or restarted journaled

67
00:02:49,628 --> 00:02:51,848
messages are played to that actor so

68
00:02:51,848 --> 00:02:53,590
that it can recover its internal state

69
00:02:53,590 --> 00:02:56,889
from these messages persistent view it

70
00:02:56,889 --> 00:02:59,680
is a persistent stateful actor that

71
00:02:59,680 --> 00:03:01,389
receives journaled messages that have

72
00:03:01,389 --> 00:03:03,370
been written by another persistent actor

73
00:03:03,370 --> 00:03:05,650
a view itself does not journal new

74
00:03:05,650 --> 00:03:08,318
messages it instead updates the internal

75
00:03:08,318 --> 00:03:10,150
state only from a persistent actors

76
00:03:10,150 --> 00:03:12,729
replicated message stream this is

77
00:03:12,729 --> 00:03:15,219
deprecated from akka 2.4 and we should

78
00:03:15,219 --> 00:03:18,189
use persistence query instead we will

79
00:03:18,189 --> 00:03:20,109
discuss persistence query in detail in

80
00:03:20,109 --> 00:03:23,109
the last video of this section async

81
00:03:23,109 --> 00:03:24,969
write journal a journal that stores a

82
00:03:24,969 --> 00:03:26,769
sequence of events sent to a persistent

83
00:03:26,769 --> 00:03:29,709
actor an application can control which

84
00:03:29,709 --> 00:03:31,509
messages are journaled and which are

85
00:03:31,509 --> 00:03:33,340
received by the persistent actor without

86
00:03:33,340 --> 00:03:35,979
being journaled the storage back-end of

87
00:03:35,979 --> 00:03:38,409
the journal is pluggable the default

88
00:03:38,409 --> 00:03:40,209
journal storage plug-in writes to the

89
00:03:40,209 --> 00:03:42,878
local file system and of course this is

90
00:03:42,878 --> 00:03:45,459
not for production for production akka

91
00:03:45,459 --> 00:03:48,459
recommends cassandra or JDBC back-end

92
00:03:48,459 --> 00:03:52,900
driver snapshots store a snapshot store

93
00:03:52,900 --> 00:03:56,430
persists snapshots of a persistent actor

94
00:03:56,430 --> 00:03:58,628
snapshots are used for optimizing

95
00:03:58,628 --> 00:04:01,840
recovery times the storage back-end of a

96
00:04:01,840 --> 00:04:04,840
snapshot store is pluggable the default

97
00:04:04,840 --> 00:04:06,818
snapshot storage plugin writes to a

98
00:04:06,818 --> 00:04:10,239
local file system you can check the full

99
00:04:10,239 --> 00:04:12,250
documentation for persistence from here

100
00:04:12,250 --> 00:04:16,180
and this is a link for Cassandra Journal

101
00:04:16,180 --> 00:04:25,769
and this one is the jdbc

102
00:04:25,769 --> 00:04:26,799
you