问题标签 [pessimistic-locking]

如果用户还没有地址，下面的代码将从外部 API 获取新地址：

如果有两个并发create_address请求进来，它们可能都会通过current_user.address.blank?检查，并且将创建两个地址（update!最后调用的地址将覆盖另一个地址）。

我们如何防止这种情况发生？我们是否需要使用某种锁定机制？

为了更好地理解悲观锁定（使用 InnoDB），我尝试在我的 Rails 应用程序中运行这段代码：

它实际上有效，account.balance然后 contains 750，然后1500在下一次命中。没有锁定，它只考虑最后一个线程，结果是500.

这是一个愚蠢的测试来尝试锁定与否之间的区别吗？我想我了解悲观锁定的原理，但不确定。

我已经了解这两种并发控制如何以简单的英语工作。然而，我更感兴趣的是如何在代码中进行悲观控制。这是我的感受，假设有两个用户正在尝试更新一个 wiki 文档

悲观控制

在这里，我们被告知要使用事务。

但是，这仍然容易覆盖以前的更新。我觉得必须在事务中进行第二次检查，以查看在 select 语句之后是否发生了任何写入，如果是，则回滚或提交。我对么？

众所周知，有两种锁定策略：乐观与悲观锁定

悲观锁定是指您锁定记录以供您独占使用，直到您完成它为止。它比乐观锁定具有更好的完整性，但需要您小心设计应用程序以避免死锁。

还知道，乐观并发控制与多版本并发控制（Oracle 或 MSSQL-Snapshot/MVCC-RC）不同：乐观与多版本并发控制 - 差异？

但是如果同时使用 OCC（乐观并发控制），两个事务之间会发生死锁吗？

我们可以说乐观锁通过降低一致性来降低死锁的可能性吗？并且只有当每次更新都在一个单独的事务中时，死锁的可能性是 0%，但这是最小的一致性。

Rails 指南和许多其他教程向我展示了如何挽救ActiveRecord::StaleObjectError异常并在乐观锁定中重试。我只是好奇我可以在悲观锁定场景中做同样的事情。

任何答复表示赞赏！:D

我正在使用 Spring-Data-Jpa 并使用 @Lock 注释（PESSIMISTIC_WRITE）来获取数据库（Oracle）锁。我需要帮助了解以下情况是否会导致数据库死锁。

1. 事务 1（PROPAGATION_REQUIRES_NEW，ISOLATION_DEFAULT）一个对说教师表进行数据库锁定（说锁定被 id=1 的行接管）。它尝试在子表中插入一条新记录，比如会议。教师表上未进行任何更新
2. 事务 1 正在进行时。事务 2(PROPAGATION_REQUIRED, ISOLATION_DEFAULT) 尝试更新教师表（id=1 的行）。它不需要数据库锁。
3. 由于锁已被 id 1 的行接管。事务 2 必须等待事务 1 结束。

这种情况会导致数据库死锁吗？

根据文档，如果尝试锁定并且对象已经被锁定，则事务将不会回滚并引发 LockTimeoutException。

什么情况下使用EntityManager会抛出PessimisticLockException？

我一直在尝试使用 Transaction Scope 实现 EF 上下文的悲观锁定。

楷模：

控制器：

现在我正在寻求批准下面描述的行为应该起作用，如果它不起作用，我很高兴听到反馈或建议以使其成为可能。

预期行为：

假设我们有 3 个线程： A - 首先调用 Join()；B - 调用 List(); C - 第二次调用 Join()。

房间容量为 1。

这就是我期望发生的事情：A 调用 Join()。方法检查它是否可以加入——看起来是肯定的，所以它进入了 TransactionScope。这时，B 调用 List()——因为 A 还没有完成 Join()，B 认为房间里没有用户。这里重要的是 B 不会等到 A 完成事务，而是会访问最后提交的行版本。现在，C 正在调用 Join()。因为 A 还在处理事务，所以 C 对房间的初始测试成功，所以它也进入了 TransactionScope。但是因为 A 还没有完成，所以 C 现在应该等待它。A完成交易，房间内的用户数现在为1。A解锁交易，C进入。它再次获取 Room 模型，测试容量只是为了发现它不能加入，所以抛出异常。

我的事情可能会破坏：

我不确定 IsolationLevel.RepeatableRead。在文档中，据说在事务期间可以读取但不能修改易失性数据。交易期间可以添加新数据。. 一方面，我希望这将允许 List() 方法按原样读取行并且不会等待 TransactionScope 完成。此外，它应该只锁定行，而不是表，因此可以添加新的房间。但是我担心当A还在运行时它不会阻塞锁C的TransactionScope。最后，我不确定“在事务期间可以读取但不能修改易失性数据”是否也适用于 TransactionScope。

总结一下：请告诉我我的代码是否会按预期运行，如果没有，我应该做哪些调整才能实现这一目标？提前致谢。

我正在阅读有关数据库锁定（悲观，乐观）机制的信息，

会话 1:
t1: 打开事务:
t2: sleep(3 sec)
t5: updte user set name='x' where id =1

会话 2: t2:update user set name='y' where id=1

我的疑问是： 1. t5 会发生什么 2. 它是否必须与隔离级别做任何事情？如果是的话，不同隔离级别的行为会是什么。3. database(mysql,oracle)是否只做悲观锁？

我正在开展一个逐步淘汰遗留应用程序的项目。在此过程中，作为临时解决方案，我们使用数据库与遗留应用程序集成。

遗留应用程序使用具有可序列化隔离级别的事务。由于数据库与遗留应用程序的集成，我目前最好使用相同的悲观并发模型和可序列化的隔离级别。

这些序列化事务不仅应该包含在 SaveChanges 语句中，还应该包括一些数据读取。

我这样做是通过

• 在我的 DbContext 周围创建一个带有序列化隔离级别的 transactionScope。
• 创建一个 DbContext
• 做一些阅读
• 对对象进行一些更改
• 在 DbContext 上调用 SaveChanges
• 提交事务范围（从而保存更改）

我的想法是，这将我的整个读取和写入包装到序列化事务中，然后提交。

我认为这是一种悲观并发的方式。

但是，阅读这篇文章，https://docs.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/handling-concurrency-with-the- entity-framework-in-an-asp-net-mvc-application 声明 ef 不支持悲观并发。

我的问题是：

• A：EF 是否支持我在读写时使用可序列化事务的方式
• B：将读取和写入包装在一个事务中可以保证我的读取数据在提交事务时不会更改。
• C：这是悲观并发的一种形式，对吧？