.NET：在线悲观锁、在线乐观锁、离线悲观锁、离线乐观锁代码示例

名称解释

悲观锁

定义：我修改数据的时候，不允许别人修改数据。

意图：并发很容易发生（悲观者经常认为某件坏事会发生在自己身上）。

场景：绩效评分的过程，因为每个评估人评分后都要修改评估结果表的同一行记录，而且经常是在同一个时间段进行的评分，评分的过程就适合用悲观锁。

乐观锁

定义：谁都可以修改数据，提交的时候和数据库做比较，如果数据在这期间发生了变化，有两种处理思路：1、失败；2、合并后提交。

意图：并发不容易发生（乐观者经常认为某件坏事不会发生在自己身上）。

场景：多个人事管理员都可以修改劳动合同，因为这种并发场景很少发生，因此此处采用乐观锁会好很多。

离线

定义：也叫长事务；一次业务过程需要多次的和服务器通信。

意图：业务要求。

场景：修改审批流程的过程会持续多个请求，多个请求必须作为一个长事务对待。

在线

定义：也叫短事务；一次业务过程只和服务器通信一次。

意图：业务要求

场景：多数业务属于这种场景。

在线悲观锁

代码示例

请查看我的这篇博客.NET：脏读、不可重复读和幻读代码示例，基本上将隔离基本设置为“可重复读”就可以满足隔离要求。

在线乐观锁

代码示例

        [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();
            }
        }

此处利用了EntityFramework自带的乐观并发机制（版本字段），多数ORM框架都提供这种支持，自己实现也不难，在此就不说了。

离线悲观锁

难点是解决离线悲观锁的获取和释放时机，常见的思路是打开Form时判断是否被锁，如果没有被锁，就获取锁，关闭Form时释放锁，会话过期时释放所有锁。锁的管理接口如下：

    public interface I离线悲观锁管理接口
    {
        bool 是否被锁(Guid 单据标识);

        void 获取锁(Guid 用户标识, Guid 单据标识);

        void 释放锁(Guid 用户标识, Guid 单据标识);

        void 释放锁(Guid 用户标识);
    }

离线乐观锁

服务器端代码和“在线乐观锁”一样，唯一要处理的是在长事务过程中如何在多个请求中存储和传输“版本字段”，常见的方式有url参数和页面html等，在此就不说了。