数据库访问中的锁定策略

核心提示： TRANSACTION_READ_COMMITTED 在 DB2 中称为 Cursor Stability，数据行只是在游标定位它们时才锁定，数据库访问中的锁定策略(8)，一旦获取下一行之后，锁将被解除，因此，我们无法预先确定是使用乐观锁定策略还是悲观锁定策略，被更改的数据行在事务结束之后被解除

TRANSACTION_READ_COMMITTED

在 DB2 中称为 Cursor Stability。数据行只是在游标定位它们时才锁定，一旦获取下一行之后，锁将被解除。被更改的数据行在事务结束之后被解除锁定。在此隔离级别上允许进行幻象行和不可重复读取，但未提交行不可见。

TRANSACTION_READ_UNCOMMITED

事务之间未隔离，只读游标可访问其他事务未提交的更改。但是，更新游标的行为与 TRANSACTION_READ_COMITTED 相同。

注意，SELECT 语句获取的锁为共享锁，它们不会阻止其他事务读取数据（在其他事务使用的隔离级别的约束内）。

建议

通常只有在少数例外情况下才使用 Read Committed 之外的其他隔离级别。但是，对于实体 Bean 则可不遵循此规则，由于该模型本身的特性，多数悲观锁定访问都需要至少 Repeatable Read。此外，在只读表上频繁使用的查询也可使用 Read Uncommitted。

必须谨慎使用悲观会话锁定，因为它在业务流程（包括用户思考时间）中序列化数据访问。

如果使用悲观会话锁定，它通常只用于阻止其他用户进行更新，而不是阻止对锁定数据的读取。

无论是逻辑锁还是物理锁，都应该作为可靠的集中式资源在数据中维护。在设计评审中，必须进行锁定模式的评审。

系统级的锁定表通常被认为是系统中的热点。但是，这可能并不是主要的问题，因为锁表通常较小，并且可能由数据库管理器完整地保存在内存中。这最适用于短时间锁，例如事务内的名称空间锁。它还可用于长时间的会话锁，但需要进行清理以避免表过度增长。

会话锁还可保存在被锁定的表中（或表集合的根表中）。如果在单个表中需要维护多种锁类型，那么可将其移动到其独立的子表或全局锁表中。

悲观事务锁应遵循最佳时间以防止死锁，包括减少锁保持期间的业务逻辑，并按常规的顺序访问数据库表。

乐观事务锁不能用于在单个 UPDATE 语句中更新数据行集合，因此在这种情况下，很难进行错误处理。

结束语

很明显，锁定是非常复杂的问题，需要人们清楚地认识和理解，这是非常重要的。为了提供可供讨论的标准语言，本文介绍了事务锁定和会话锁定的概念，并讨论了不同的锁定模式及其优缺点。尽管我们提供了一些一般性建议，但由于锁定使用更多地依赖于具体的应用程序以及用户的使用方式，因此很难概括出硬性的使用规则。本文的最重要一点是，锁定并不仅仅是数据库管理系统就能帮您完成的事。它也是设计的组成部分，并影响整个系统的总体可用性。因此，我们无法预先确定是使用乐观锁定策略还是悲观锁定策略，通常需要提出并讨论这些设计问题以确保解决方法能满足功能和非功能性需求。