database - 锁定机制(悲观/乐观)与数据库事务隔离级别有何关系？

Question

我正在编写一个 Web 应用程序，两个不同的用户可以在其中更新事物列表，例如待办事项列表。我已经意识到，乐观锁定机制效果最好，因为我不希望出现高争用情况。

我一直在查看事务隔离级别，现在我有点困惑。看起来不同的事务隔离级别也解决了类似的问题。

这两个不同的概念如何相互关联？如果可能，举一个简单的例子。

Answer 1

这两者都与数据一致性和并发访问有关，但它们是两种不同的机制。

锁定会阻止对某些对象的并发访问。例如，当您尝试更新待办事项列表项时，使用悲观锁定的数据库会在记录上放置一个行锁，直到您提交或回滚该事务，这样就不允许其他事务更新同一记录。乐观锁定是应用程序端检查记录的时间戳/版本在获取和尝试更新之间是否发生了变化。这与事务隔离级别无关。

事务隔离是关于读取一致性。

• 读取未提交级别允许 session 查看其他 session 未提交的更改
• Read committed 级别允许 session 仅查看其他 session 的已提交更改
• 可序列化级别允许 session 仅查看事务开始前提交的更改

看看下面的例子，我指出了不同事务隔离级别的查询结果。

SESSION 1                                  SESSION 2
--------------------------------           --------------------------------------
SELECT count(*) FROM test;
=> 10
                                           INSERT INTO test VALUES ('x');

SELECT count(*) FROM test;
=> 10 with read committed/serializable
=> 11 with read uncommited (dirty read)
                                           COMMIT;

SELECT count(*) FROM test;
=> 10 with serializable
=> 11 with read uncommitted/read committed

有四种 ANSI 指定的事务隔离级别(上面示例中未提及的一种是“可重复读取”)，除了可序列化之外，所有这些都存在一些异常。请注意，它与锁定无关。

您可以查看有关此 here 的 Oracle 文档, 这些概念非常普遍。

最后，您使用乐观锁定的方法对于 Web 应用程序似乎是明智的。很可能您获取一个列表项并在两个不同的 HTTP 请求中更新它。在获取之后通过显式锁定记录来保持事务打开是不可能的(或者至少是不明智的)(你怎么知道第二个请求是否会到达？)乐观锁定可以优雅地处理这个问题。