数据库访问中的锁定策略

核心提示： 乐观会话锁定还可用于消息顺序无法保证的事件驱动或基于消息的系统中，在通知复制数据库更改的消息中可能包含数据的当前版本号或时间戳，数据库访问中的锁定策略(5)，如果接收方的数据已发生具有更高序列号（或更新的时间戳）的更改，则较早的更改可能会被拒绝，因此获得锁的应用程序始终需要在更新数据之前检测锁是

乐观会话锁定还可用于消息顺序无法保证的事件驱动或基于消息的系统中。在通知复制数据库更改的消息中可能包含数据的当前版本号或时间戳。如果接收方的数据已发生具有更高序列号（或更新的时间戳）的更改，则较早的更改可能会被拒绝。

悲观会话锁定

在本方案中，通过逻辑锁（而不是物理锁）来对在较长时间中使用的数据行进行标记。这通常用在当存在居间用户界面交互和数据库锁定不足的时候。有几种常用方法可实现这一模式，其中包括在表中添加额外的列（例如锁标记、锁用户 ID、锁时间戳等），使用独立的锁表，或者使用外部锁机制，例如内存中的散列表（因明显的伸缩性原因，不推荐使用）。这在 Fowler (op. cit.) 中描述为悲观离线锁。悲观会话锁不会阻塞锁（因此不会引起死锁），当第二个尝试锁定数据行的事务在读取数据时将发现锁，它会承认锁，并通知用户当前数据不可用。

悲观会话锁通常为写入锁，它们允许其他用户读取锁定的数据，除非遇到不能读取的情况。例如，当数据处于重要的重组过程中时，访问数据可能获得无效的结果。

如果只有单一类型的锁关联到给定表，那么可以添加额外的列到原始表中来控制锁定。但是，如果同一个表关联多种类型的锁，例如读取和写入锁，或不同的表分组被锁定为粗粒度集合（稍后讨论），那么可以使用锁表来关联到主表。

使用悲观会话锁时还需注意一些问题：

锁可以存在于多次用户交互之间，这意味着它们可能会丢弃，因此需要制定锁的超时策略。

在某些情况，可能需要强制覆盖会话锁，例如医院系统中的急诊，但这种覆盖需要进行记录以便进行审核。

如上所述，由于可以删除悲观会话锁，因此获得锁的应用程序始终需要在更新数据之前检测锁是否有效。在此方面，它需要以乐观锁的方式进行处理。