1
00:00:00,410 --> 00:00:04,580
Our data concurrency solution prevents
the last one in wins scenario,

2
00:00:04,580 --> 00:00:09,050
but it doesn't give users much
to go on when a problem arises.

3
00:00:09,050 --> 00:00:11,940
We're risking that users might
just fall into the habit of

4
00:00:11,940 --> 00:00:14,450
always choosing the client wins option,

5
00:00:14,450 --> 00:00:19,220
in order to not lose their updates
which could result in data loss.

6
00:00:19,220 --> 00:00:22,930
We could extend our solution in order
to give the user more information.

7
00:00:22,930 --> 00:00:26,710
For instance, we could display detailed
information about which values have

8
00:00:26,710 --> 00:00:30,930
changed, so that users can determine
the best way to resolve the conflict.

9
00:00:30,930 --> 00:00:33,650
How to do this is beyond
the scope of this workshop, but

10
00:00:33,650 --> 00:00:37,100
if you're interested in learning more,
see the teacher's notes.

11
00:00:37,100 --> 00:00:38,860
After updating the comic book edit and

12
00:00:38,860 --> 00:00:42,480
delete processes to support
optimistic concurrency controls.

13
00:00:42,480 --> 00:00:46,140
You might be wondering,
is all of this effort necessary?

14
00:00:46,140 --> 00:00:50,530
Do you really need to implement data
concurrency controls in your web apps?

15
00:00:50,530 --> 00:00:52,450
Well, it depends,

16
00:00:52,450 --> 00:00:56,580
it depends on the number of users
your app has in any given user role.

17
00:00:56,580 --> 00:01:01,030
And it depends on the criticalness
of not having accidental data loss.

18
00:01:01,030 --> 00:01:04,690
And just like with any feature
that you could implement,

19
00:01:04,690 --> 00:01:07,320
it also depends on your overall budget and
schedule.

20
00:01:08,360 --> 00:01:12,230
After weighing the options with your
project stakeholders, and users, or

21
00:01:12,230 --> 00:01:16,760
clients you might find that it's far more
important to implement other features

22
00:01:16,760 --> 00:01:20,430
rather than investing and
implementing data concurrency controls.

23
00:01:20,430 --> 00:01:24,050
Or you might find that your web
app simply doesn't need it.

24
00:01:24,050 --> 00:01:28,374
Whatever decision you make, the important
point is to make an informed decision.

25
00:01:28,374 --> 00:01:32,320
Leveraging EF support for
optimistic concurrency, isn't the only

26
00:01:32,320 --> 00:01:36,750
option available to you when implementing
data concurrency controls in your web app.

27
00:01:36,750 --> 00:01:41,010
It's also possible to implement
pessimistic concurrency controls.

28
00:01:41,010 --> 00:01:42,900
When a user needs to edit a record,

29
00:01:42,900 --> 00:01:46,180
they first need to place
an explicit lock on the record.

30
00:01:46,180 --> 00:01:48,340
If the record already has a lock on it,

31
00:01:48,340 --> 00:01:52,110
they'll be notified which user
placed the lock on it and when.

32
00:01:52,110 --> 00:01:56,060
When the user has finished updating
the record, the lock is released.

33
00:01:56,060 --> 00:01:59,450
Sometimes this process is
known as explicit locking.

34
00:01:59,450 --> 00:02:01,750
Since EF doesn't provide any support for

35
00:02:01,750 --> 00:02:05,560
it, implementing pessimistic
concurrency controls typically requires

36
00:02:05,560 --> 00:02:09,500
more effort on the developers part
than its optimistic counterpart.

37
00:02:09,500 --> 00:02:13,270
Even when you're implementing optimistic
concurrency controls, there's a lot of

38
00:02:13,270 --> 00:02:17,440
flexibility with how you communicate
concurrency conflicts to users.

39
00:02:17,440 --> 00:02:20,900
At the beginning of this video we
discussed the possibility of providing

40
00:02:20,900 --> 00:02:25,890
detailed error information to users,
so they could see specific information

41
00:02:25,890 --> 00:02:29,440
down to the field level about
the concurrency conflict.

42
00:02:29,440 --> 00:02:32,770
Generally speaking providing
more information to users

43
00:02:32,770 --> 00:02:35,300
will help them make better decisions.

44
00:02:35,300 --> 00:02:39,650
Also, the sooner that users know that
their update will fail, the better.

45
00:02:39,650 --> 00:02:43,700
For instance, you could use client-side
javascript code to alert users when

46
00:02:43,700 --> 00:02:47,580
the record they're editing has changed on
the server, without having to wait for

47
00:02:47,580 --> 00:02:50,480
the user to submit or
post their changes to the server.

48
00:02:51,588 --> 00:02:54,560
We've just crushed the surface
of data concurrency, and

49
00:02:54,560 --> 00:02:56,690
concurrency controls in this workshop.

50
00:02:56,690 --> 00:03:00,970
As usual, see the teacher’s notes for
links and additional resources.

51
00:03:00,970 --> 00:03:02,900
Thanks for watching, and
we’ll see you next time.