在上一篇<学习MVC之租房网站（九）-房源显示和搜索>完成了房源的显示、检索，然后是用户的预约看房，以及后台操作员对预约看房的跟单操作。
预约看房仅有将预约信息保存到对应表的操作，预约表有字段标识一条预约是否被受理，接下来后台操作员对未受理的预约请求进行跟单时，会对这个字段的状态做修改，为了防止高并发时多人同时修改，要设计到数据库锁
一数据库锁
数据库锁分为乐观锁和悲观锁两种，两种锁都是为了保证数据库的单元数据不会被多人同时操作。
a)悲观锁，悲观锁默认自己在操作数据时，别人一定也会读取，所以每次都会在操作前加锁。查了一下，SqlServer中的悲观锁有十几种之多，这儿仅仅是做初步了解，悲观锁上锁后，连查询也不能进行；从锁的范围来分类，悲观锁又分为表锁和行锁。
b)乐观锁，乐观锁则默认自己操作数据时，别人不会同时操作。乐观锁要配合表的特殊字段TimeStamp或RowVersion来使用，通过观察操作数据前后TimeStamp或RowVersion的变化情况来判断操作是否成功。
c)悲观锁上锁后别人不能操作，对系统影响很大。在读取多于写入的系统中，适合使用乐观锁，乐观锁允许更大的吞吐量，但如果是经常写入的系统，就只能使用悲观锁了。另外，乐观锁如果上锁失败会比较尴尬，类似抢红包时，虽然点击了“打开”，但进去后红包却已被抢光了。
二数据库锁的使用
a)悲观锁的使用。在原生SQL中，可以使用With(xLock)、With(RowLock)等来上锁，EF则不支持悲观锁，若要使用，可借助EF来传递原生SQL
b)乐观锁的使用。需要先在数据表增加类型为TimeStamp的字段，新版SqlServer也可以使用RowVersion类型。在EF中使用时，实体要对应添加byte[]类型的属性，FluentAPI配置方法为Property(..).IsRowVersion。EF在SaveChange时会根据TimeStamp判断是否更新成功，如果失败，会抛出DbUpdateConcurrencyException异常，所以更新的代码可以包裹在try-catch中。
注：
课程内容来自如鹏网（www.rupeng.com），专注于大学生就业的在线教育平台；