定义：我修改数据的时候，不允许别人修改数据。
意图：并发很容易发生（悲观者经常认为某件坏事会发生在自己身上）。
场景：绩效评分的过程，因为每个评估人评分后都要修改评估结果表的同一行记录，而且经常是在同一个时间段进行的评分，评分的过程就适合用悲观锁。
定义：谁都可以修改数据，提交的时候和数据库做比较，如果数据在这期间发生了变化，有两种处理思路：1、失败；2、合并后提交。
意图：并发不容易发生（乐观者经常认为某件坏事不会发生在自己身上）。
场景：多个人事管理员都可以修改劳动合同，因为这种并发场景很少发生，因此此处采用乐观锁会好很多。
定义：也叫长事务；一次业务过程需要多次的和服务器通信。
意图：业务要求。
场景：修改审批流程的过程会持续多个请求，多个请求必须作为一个长事务对待。
定义：也叫短事务；一次业务过程只和服务器通信一次。
意图：业务要求
场景：多数业务属于这种场景。
[TestMethod] [ExpectedException(typeof(DbUpdateConcurrencyException))] public void 乐观锁测试() { using (var context1 = new TestEntities()) { context1.Users.First().Name = "李妞妞1"; using (var context2 = new TestEntities()) { context2.Users.First().Name = "李妞妞2"; context2.SaveChanges(); } context1.SaveChanges(); } }
难点是解决离线悲观锁的获取和释放时机，常见的思路是打开Form时判断是否被锁，如果没有被锁，就获取锁，关闭Form时释放锁，会话过期时释放所有锁。锁的管理接口如下：
public interface I离线悲观锁管理接口 { bool 是否被锁(Guid 单据标识); void 获取锁(Guid 用户标识, Guid 单据标识); void 释放锁(Guid 用户标识, Guid 单据标识); void 释放锁(Guid 用户标识); }
.NET：在线悲观锁、在线乐观锁、离线悲观锁、离线乐观锁代码示例
原文：https://www.cnblogs.com/bangguo/p/12586161.html