1
00:00:02,090 --> 00:00:03,970
So how does a transaction work?

2
00:00:04,070 --> 00:00:07,400
Now for a transaction, we need a so-called session.

3
00:00:07,400 --> 00:00:14,180
We haven't worked with sessions before but a session basically means that all our requests are grouped

4
00:00:14,240 --> 00:00:20,930
together logically you could say. You create a session and you store it in a constant let's say here, with

5
00:00:20,930 --> 00:00:22,820
db getMongo,

6
00:00:22,820 --> 00:00:28,820
this gives you access to the mongo server basically, start session,

7
00:00:28,840 --> 00:00:36,190
now I have a session stored in there. Now that session again basically is just an object that now allows

8
00:00:36,190 --> 00:00:39,880
me to group all requests that I send

9
00:00:39,940 --> 00:00:44,570
based on that session together, that is how you can think about it.

10
00:00:44,770 --> 00:00:49,850
Now you can use that session to start a transaction,

11
00:00:49,900 --> 00:00:52,800
so start transaction is something you can do.

12
00:00:53,080 --> 00:00:58,000
Now important, that session is required because technically every command I issue here is sent to the server

13
00:00:58,090 --> 00:01:03,730
and then normally the server would forget me and therefore, we need that session so that when I send

14
00:01:03,730 --> 00:01:09,160
something based on that session, the server remembers oh that session which behind the scenes is managed

15
00:01:09,160 --> 00:01:11,130
through a session key and so on,

16
00:01:11,200 --> 00:01:17,110
I know that one, that command you just sent me should be considered in the context of the other commands

17
00:01:17,110 --> 00:01:18,770
you sent me based on that session,

18
00:01:18,820 --> 00:01:21,420
that is how you can think about that.

19
00:01:21,430 --> 00:01:25,420
So now we started the transaction,

20
00:01:25,560 --> 00:01:27,330
we can now get access to a collection,

21
00:01:27,390 --> 00:01:34,940
so let's say to users and products. So I'll create a new constant, usersC for collection and we use

22
00:01:34,940 --> 00:01:42,690
that session again, get our database on which this session was created, get a database for that session now

23
00:01:42,870 --> 00:01:44,160
or for this operation

24
00:01:44,400 --> 00:01:51,380
and here the database is blog, that is the database I created earlier if you remember here, use blog

25
00:01:53,490 --> 00:01:55,560
and then we get access to a collection,

26
00:01:55,590 --> 00:01:56,690
the users collection

27
00:01:59,390 --> 00:02:03,580
and get database definitely runs if you type it correctly.

28
00:02:04,940 --> 00:02:07,800
And now I have that usersC so

29
00:02:07,890 --> 00:02:08,870
let's name it

30
00:02:08,860 --> 00:02:09,860
usersCol now.

31
00:02:09,860 --> 00:02:10,050
Ok,

32
00:02:10,070 --> 00:02:13,570
so now I got the users collection saved here with the right command.

33
00:02:13,880 --> 00:02:19,670
Now let's repeat that for the posts call,

34
00:02:19,690 --> 00:02:24,320
here we get access to the block database but now to the posts collection.

35
00:02:24,330 --> 00:02:28,950
Ok so now we started a transaction and we got access to our collections,

36
00:02:28,960 --> 00:02:34,970
now we can write all the commands we want to execute against these collections here.

37
00:02:35,400 --> 00:02:39,490
So now first of all, what I'll quickly do without session is I'll execute

38
00:02:41,390 --> 00:02:48,650
db users find pretty. Now important, since I don't run this against a session, this executes as normal and I get

39
00:02:48,650 --> 00:02:51,420
my object ID and the object in general which I need,

40
00:02:51,590 --> 00:02:56,780
so this is now not included in the transaction because it's not included in the session on which I started

41
00:02:56,840 --> 00:02:57,940
the transaction,

42
00:02:58,280 --> 00:03:00,350
I just needed to get the ID right now,

43
00:03:00,350 --> 00:03:07,940
so now I can go back and use my usersCol which is this object which is basically a pointer at my collection

44
00:03:08,090 --> 00:03:10,680
but also mapped to this session you could say.

45
00:03:10,720 --> 00:03:14,950
So now I'm using the collection in the context of my session through that constant

46
00:03:15,260 --> 00:03:21,620
and there, I can now use my normal operations inserting, finding, updating, that all works.

47
00:03:21,620 --> 00:03:31,170
So here I can now basically run delete one, delete one and search for ID equal to objectID. If I now

48
00:03:31,170 --> 00:03:38,080
hit enter, this was acknowledged and deleted but if I repeat db users find, you see the user still

49
00:03:38,080 --> 00:03:38,980
is in the database,

50
00:03:39,010 --> 00:03:40,830
so it hasn't been deleted yet,

51
00:03:40,870 --> 00:03:43,180
it was just saved as a to-do

52
00:03:43,180 --> 00:03:51,100
you could say. Now I will use my posts collection, so postsCol which I created here

53
00:03:52,200 --> 00:03:59,970
and I will use that to then delete many items in there based on the userid which of course is that

54
00:03:59,970 --> 00:04:03,660
same object id as I used for deleting the user.

55
00:04:03,660 --> 00:04:08,220
Now this was also acknowledged and you say, it says deleted too but it didn't

56
00:04:08,220 --> 00:04:14,970
yet write this to the database as I can prove by looking into my posts with db, not with the

57
00:04:14,970 --> 00:04:15,830
session,

58
00:04:15,840 --> 00:04:23,190
now you see the posts are still there. Because to really make this work or to really commit these changes

59
00:04:23,190 --> 00:04:34,380
to the real database so to say, I have to run session commit transaction, there also would be abort transaction,

60
00:04:34,730 --> 00:04:37,180
so in case you don't want to continue, you can abort it,

61
00:04:37,250 --> 00:04:42,290
you should do that to cleanly close it though but now if you do that, the changes will not be applied

62
00:04:42,290 --> 00:04:44,120
to the database, with commit

63
00:04:44,120 --> 00:04:44,890
they will.

64
00:04:45,080 --> 00:04:48,430
So if I run this, it failed initially,

65
00:04:48,430 --> 00:04:54,570
now I repeated it without all these db in-between queries which seem to have messed it up.

66
00:04:54,640 --> 00:05:02,260
If you just execute the steps basically as I explained them but now simply creating a session, then getting

67
00:05:02,260 --> 00:05:07,260
access to your collections, then starting the transaction and then just specifying the two commands that

68
00:05:07,270 --> 00:05:09,990
belong to the transaction and then committing it,

69
00:05:10,120 --> 00:05:11,090
then it works

70
00:05:11,140 --> 00:05:17,980
and now if I dive into my database and find my users, you'll see the user is gone, the one user ahead.

71
00:05:17,980 --> 00:05:24,250
So this is how transactions work, you get access to a session, you then based on that session,

72
00:05:24,250 --> 00:05:30,130
that's always important, you use that session to then store a reference to your collections in some variables

73
00:05:30,130 --> 00:05:31,030
or constants

74
00:05:31,090 --> 00:05:36,910
and you do that from your native drivers, for node and so on of course too, then you start a transaction

75
00:05:36,940 --> 00:05:44,140
on the session and then you'd execute your manipulating queries. Finding doesn't make much sense in here

76
00:05:44,350 --> 00:05:47,380
because well what would you find in there, in the transaction,

77
00:05:47,380 --> 00:05:50,880
the transaction is all about safely changing data, like here

78
00:05:50,930 --> 00:05:55,310
I delete the user, I delete the posts and then you commit the transaction.

79
00:05:55,360 --> 00:05:58,050
You could also abort it with abort transaction

80
00:05:58,090 --> 00:05:59,730
in case you don't want to continue

81
00:05:59,860 --> 00:06:01,120
but if you want to continue, 

82
00:06:01,150 --> 00:06:03,600
well you can just commit it. Now

83
00:06:03,620 --> 00:06:10,120
also important to understand here is that for this transaction, if it somehow would fail, if something

84
00:06:10,120 --> 00:06:10,980
would go wrong,

85
00:06:11,020 --> 00:06:17,600
let's say the user was deleted but the posts weren't, then it will roll back these operations in

86
00:06:17,920 --> 00:06:22,160
commit transaction and thereafter your database will be in the same state as before.

87
00:06:22,270 --> 00:06:26,590
So these actions either succeed together or they fail together,

88
00:06:26,590 --> 00:06:29,050
that is the idea behind transactions.

89
00:06:29,050 --> 00:06:36,820
Now you might remember this atomicity topic I talked about way earlier in the course. There I explained

90
00:06:37,150 --> 00:06:40,050
that mongodb is atomic on a document level,

91
00:06:40,090 --> 00:06:44,530
so if you write a document, it either is written entirely or not written at all.

92
00:06:44,530 --> 00:06:51,520
This basically gives you atomicity across multiple operations, so across multiple steps or even something

93
00:06:51,610 --> 00:06:57,890
like delete many. Normally each operation on its own would be guaranteed to work

94
00:06:57,900 --> 00:07:02,560
but if you delete two posts here, you're not guaranteed that both deletes will work,

95
00:07:02,560 --> 00:07:09,040
so with a session, you could even just wrap delete many or insert many to guarantee that either all documents are deleted

96
00:07:09,040 --> 00:07:11,260
or inserted or none at all.

97
00:07:11,260 --> 00:07:14,620
So you get atomicity on an operation level

98
00:07:14,620 --> 00:07:20,290
so to say and not just on a document level. That is the idea behind transactions and that is a useful

99
00:07:20,290 --> 00:07:25,590
feature for situations where you know that some operations depend on each other.

100
00:07:25,660 --> 00:07:31,090
You should definitely not overuse it though, if you don't need it don't use it because obviously this

101
00:07:31,090 --> 00:07:34,510
takes a bit more performance than a normal delete or insert,

102
00:07:34,600 --> 00:07:40,120
so only use it if you know you need that cross operation consistency.