设计模式-离线并发模式－悲观离线锁（Pessimistic Offline Lock）

作用

每次只允许一个业务事务访问数据以防止并发业务事务中的冲突。
悲观离线锁从一开始就避免冲突，它要求业务事务在对数据进行操作前必须获取该数据的锁。因此在大多数情况下，一旦开始了一个业务事务，就能确信不会由于并发冲突而驳回提交的数据。

运行机制

• 通过三步实现悲观离线锁：决定使用哪种锁；构建一个锁管理对象；定义业务事务使用锁的过程。
• 锁类型：

1. 独占写锁（exclusive write lock）。只有业务事务进行编辑会话数据时才需要，它忽略了对数据的读。
2. 独占读锁（exclusive read lock）。业务事务为了读出数据才获得该锁，它影响系统的并发行。
3. 读/写锁（read/write lock）。即提供互斥读锁的限制，又有互斥写锁的限制。

• 读/写锁的关系：

1. 读锁和写锁是互斥的。如果记录被其他事务加了读锁，就不能再加写锁；如果记录被其他事务加了写锁，就不能在家读锁。
2. 并发的读锁是允许的。一个读锁能防止其他业务事务修改记录。

• 定义锁管理对象。锁管理对象负责授予或者拒绝业务事务对获得或释放锁的请求。锁管理对象需要知道锁的拥有者（业务事务）和加锁记录。
   
• 加锁对象是记录或某些对象，实际上只对ID或主键加锁。
• 对任何想加锁的对象，对锁表的访问必须序列化。获得锁就是成功象锁表插入一行数据，释放锁就是删除插入的那行数据。
• 锁管理时的顺序性导致了性能瓶颈。
• 在使用悲观锁模式的系统事务中，比如“select for update”或者实体EJB，可能出现死锁。比如两个用户需要资源A和B，其中一个获得了A的锁，另一个获得了B的锁，两个事务永远等待对方释放锁。一般采用超时检测处理。
• 会话丢失，锁超时检测。
   

使用时机

悲观离线锁适合用在冲突率高的并发会话中，也适合用在冲突处理代价很高的情况。
尽量本着这样的原则：悲观离线锁是乐观离线锁的补充，在真正需要时才用到它。
使用悲观离线锁之前可以考虑长事务。
充分利用系统自带的悲观锁机制，如“select for update”以及实体EJB。

示例－简单锁管理对象（Java）

示例说明：本示例构造一个独占读锁的锁管理对象，然后演示如何处理跨系统事务的业务事务。由于悲观离线锁离不开应用会话、业务事务、所管理和系统事务，因此本示例需要构造一个框架来演示锁的工作机制。
step1：定义锁管理器接口
锁管理器中获取锁和释放锁，具体表现为对锁表lock的操作，插入成功表示加锁，删除插入的记录，表示释放锁。
 

step2：定义锁管理器实现部分－获取锁和释放锁

step3：构造一个框架－背景是Web应用，并且自行定义一个应用会话而不完全采用HTTP会话，应用会话要记录自己的ID、用户名以及领域对象的标识映射。

step4：本例将使用前端控制器处理请求，所以首先定义命令（command）。下面定义命令的通用功能－创建新会话和找到应用会话。

step5：定义具体的命令，包括编辑一个领域对象和保存一个领域对象