问题标签 [pessimistic-locking]

我有个问题。我想了解为什么我可以从一个悲观的写锁定实体中获取属性：

但我做不到：

它适用于悲观读锁模式，但不适用于悲观写模式。

有谁知道为什么我可以在写模式下读取它但不能将它设置为另一个实体？

有没有办法解决它，因为我无法更改所有应用程序的模式？

我正在尝试 JPA 对数据库锁定的支持，以避免记录中的并发请求。在我的场景中，我需要使用悲观锁。我使用以下方法得到了这个：

但是通过这种方法，我处理的是 aLockTimeoutException而不是 a PessimisticLockException。具体怎么处理PessimisticLockException？

我上面代码的日志是：

并且数据库也会更新。为什么 lock() 不起作用？不是在lock() 之后其他实例无法更新吗？或者是别的什么？还是我错过了什么？

我的Rails 应用程序中有User、Order和模型。和之间存在多对多关系，和之间存在一对多关系。ContestPositionUserOrderPositionOrderUserContest

我有execute处理订单的方法的订单处理器服务。为了防止竞争条件，我使用lock!内部事务。

问题是，当我execute同时在参数中调用两个或多个具有相同顺序的方法时，有时我会陷入僵局。最奇怪的是，第一个方法开始执行，而第二个方法正在等待解锁。一切如预期。但是我的第一个方法（正在执行）是锁定在中间。更奇怪的是，该方法锁定在未处理任何锁定记录的行中。另外，如果我评论一些不相关的行，并且有时（并非总是）它会锁定不更改甚至不使用任何锁定记录的行，则方法永远执行的行可能会随机更改。

这是我的execute方法

通过在评论中处理我的意思只是将属性分配给记录。

所以这是我close_open_orders!方法的开始

但我不认为问题出在each陈述中，因为正如我所说，如果我忽略这种方法，我就会陷入僵局。

当只执行一种方法时，一切正常。我也可以附加 pg 日志，但我没有看到任何死锁：两个选择的更新订单。而不是选择，仅user.orders.open.where.not(id: order.id)此而已。在那之后不相关（或不相关？）：

如果需要，我可以添加更多的 pg 日志。

UPD我正在使用 sidekiq 异步执行作业

我有一个要求，我需要修改 6 个表中的一个字段，并且需要在单个事务中执行此操作。

所以我使用了spring @Transactional（使用默认设置）。

现在，在事务方法中获取和更新数据时，如果任何其他调用尝试访问表之一（事件），我的应用程序由于事件表上的可能锁定而被挂起，并且在应用程序日志中，我得到javax.persistence.PessimisticLockException .

我想要的是，在执行@Transactional方法时，应用程序应该服务于对数据库的所有读取请求，并且不应该因为锁定而挂起。

注意：我在嵌入式模式下使用 derby 数据库。MySql 一切正常。

请帮忙。

谢谢。

有没有办法检查实体是否被教义锁定？

就我而言，我需要从 EventListener 知道相关实体是否已锁定在当前事务中以防止逻辑错误。

这样的事情会很棒：

我想避免使用其他供应商。

我有一个Django项目，它使用MySQL v5.5后端和InnoDB存储。
为了避免数据库中的竞争条件更新，我使用 select_for_update 来锁定行。现在如果这个锁保持很长时间，任何对锁定行的查询都会超时。
我想通过以下选项之一避免这种情况：

1. 跳过锁定的行，类似于SKIP LOCKED选项。
2. 如果您正在查询的某些行被锁定，则立即返回，类似于NOWAIToption。
3. 减少特定查询的锁定等待超时时间。

如何使用 Django ORM 执行这些操作？

Right now I am preventing several users from several instances to access the same row of my database table with a PESSIMISTIC_WRITE lock. The transaction which locks the row has the default isolation level set which is REPEATABLE_READ.

Under the circumstance that the table is empty it gets refilled with new entries and here it gets strange. The insert is an async bulk insert that runs in a seperate transaction. So when this data is commited a users reads a row for update which should lock the row. Somehow this does not work anymore and several users are able to get the value from the same row.

While trying to figure this out I changed the isolation level to READ_COMMITED and the issue did not occure anymore.

Can somebody enlighten me how this is possible? What am I missing?

Here is some psyeudo code for better understanding:

Async refilling

Getting values

For locking we are using this annotation from spring data: @Lock(LockModeType.PESSIMISTIC_WRITE)

我遇到了无法解释的 DB2 隔离级别的情况。

我有一个隔离级别为 REPEATABLE_READ 的事务，它在 DB2 中对应于 READ_STABILITY。

我对 DB2 S-、U-和 X-locks 有基本的了解。

当我并行执行以下 Spring 事务时，可能会导致死锁（来自 DB2 的错误是 FILE IN USE）：

我希望 REPEATABLE_READ 隔离会在返回的行上设置 DB2 U 锁，以便并行事务排队。

相反，为了让它工作，我需要添加一个悲观的写锁：

上面的查询生成正确的锁定 SQL 并且事务工作没有死锁：

问题是，当我仍然需要手动锁定时，为什么要使用 REPEATABLE_READ 呢？我的理解是 REPEATABLE_READ 必须自己处理必要的行锁定以确保可重复读取。

我正在努力解决库存分配和并发的经典问题，我想知道是否有人可以指导我在这种情况下的最佳实践。

我的情况是，我们准备了一个带有多个“插槽”的订单，这些“插槽”将在流程的某个阶段由独特的库存物品填充，此时我想确保没有人将相同的唯一单元分配给一个插槽不同的顺序。例如，一个用户下周四想要一辆面包车，所以我保留了一个“面包车”插槽，但在稍后的时间点，我将一辆特定的车辆从院子里分配到这个插槽。我想确保两个不同的运营商下周四不能将同一辆货车分配给两个不同的客户。

我们已经有一个库存可用性检查流程，我们比较一个日期范围内的两个表的汇总，将这两个表相加的结果（一个是进货，另一个是出货）告诉我我们是否有我想要的特定项目想在这个日期分配给这个插槽，但我想防止另一个用户在同一时间点将相同的项目分配给他们自己的插槽。

我已经在这个站点上进行了一些谷歌搜索和研究，看起来我需要一个“悲观锁定”解决方案，但我不确定如何有效地实施。

分配过程将从具有实体框架的 Web API（使用 .Net 的其余 api）调用，我考虑了以下两种解决方案：

选项 1 - 让数据库处理它

在分配点，我开始一个事务并在用于评估库存可用性的两个表上获得一个排他锁。

该过程确认库存可用性，将单元分配到插槽，然后释放锁定。

我认为这将防止两个用户试图将相同的唯一单元分配给两个不同的订单的竞争条件，但我不喜欢为需要查询这些表的每个其他进程锁定两个表，直到分配过程完成，因为我认为这个可能会对尝试读取这些表的其他进程造成瓶颈。在这种情况下，我认为尝试执行重复分配的第二个进程应该排队，直到第一个进程释放锁，因为它无法查询可用性表，并且当它执行时它将无法通过可用性检查并报告缺货警告 - 如此有效地阻止第二个订单分配相同的库存。

从理论上讲，这听起来可行，但我有两个担忧；第一个是它会影响性能，第二个是我忽略了一些东西。我也是第一次在这个项目中使用 Postgres（我通常是一个 SQL Server 人），但我认为 Postgres 仍然具有执行此操作的功能。

选项 2 - 使用某种手动锁定

我认为我的情况类似于票务网站在音乐会或电影院的销售过程中遇到的情况，我看到他们设置了计时器，说“您的票将在 5 分钟内到期”，但我不知道他们是如何实现的后端的系统。他们是否在分配过程开始之前创建一个“保留”库存表，并在它们上设置某种到期时间，然后将其他尝试分配相同单位的用户“列入黑名单”，直到该计时器到期？

很抱歉，介绍很长，但我想完全解释这个问题，因为我已经看到很多关于类似场景的问题，但没有什么能真正帮助我决定如何继续。

我的问题是这两个选项中的哪一个（如果有的话）是“正确的方法”？

编辑：我见过的与这个问题最相似的是如何处理库存和并发，但它没有讨论选项 1（可能是因为这是一个糟糕的主意）