我们将 Ticket 对象队列持久化到数据库中。我们包含队列的实体如下所示：

我们有一个操作将票从一个队列移动到另一个队列（称为 changeStatus），另一个操作将新票添加到队列末尾（称为 newTicket）。

当这两个操作在同一个队列上交错时，这些操作基本上可以工作，但我们最终会在我们的队列中产生一个“间隙”。在数据库中，这看起来像表的 order 列中缺少索引，如下所示：0、1、2、4。当队列重新加载到 Java 中时，缺少的索引成为队列中的空元素。

我们在 StoreQueueCollection 对象上使用悲观锁定来防止不一致的交错更新，但它并没有像我们预期的那样工作。通过额外的日志记录，我们会看到如下奇怪的序列：

所有锁都是 LockModeType.PESSIMISTIC_WRITE，范围是 PessimisticLockScope.EXTENDED。

在这一系列执行之后，另一个线程触发一个断言，该线程检查队列中的空条目。神秘的是，队列基本是正确的（X被删除，Y被添加到最后），但是在Y之前的order列有一个空隙。

非常感谢任何关于我们做错了什么的建议！

我试图在我的 creteria 中添加一个悲观锁定，如文档 http://grails.org/doc/latest/guide/GORM.html#locking中所示，但我有一个例外：

“错误 util.JDBCExceptionReporter - 不支持功能：“FOR UPDATE && JOIN”；SQL 语句：... org.hibernate.exception.GenericJDBCException：无法执行查询”

我尝试在两个地方添加锁：

和

附加问题：使用悲观锁定关联是否正确？

谢谢

领域

数据源.groovy

我需要为休眠指定锁定模式。我在做什么：

但是当我看到提供的查询时 - hibernate 仍然没有提供SELECT FOR UPDATE

我怎样才能强制休眠做出SELECT FOR UPDATE子句？我看到的唯一情况是：

但我需要使用更复杂的查询。

我试图了解 Hibernate 中的悲观锁定机制（通过 MySQL DB）。

我尝试运行以下示例：

但是它没有给我一个错误，而是执行得很好。是否有某种我误解的概念。这种行为正常吗？

我能够完美地测试乐观锁定，因此对于悲观锁定是否存在对该概念的一些误解，或者我的代码缺少某些东西。

这是重现异常的示例项目。

此示例说明了当许多并发事务正在修改帐户余额时的问题。Account 可以绑定多个 Card 实体。交易与订单相关，并且在时间上是最后的。每个线程执行如下：

1. 客户端请求“/order/{hashId}”以获取第一个可用的 Order by given card hash id
2. 客户端为给定订单开始新的交易 - '/tx/{orderId}/start'
3. 客户完成 tx - '/tx/{txId}/stop/{amount}' 从账户余额中减去 tx 金额。

实体锁定

Account 和 Order 实体使用@javax.persistence.Version 进行版本控制。在最后一步 Account 实体被悲观写锁锁定：

测试

要测试并发访问，请使用JMeter脚本 src/main/resources/StressTest.jmx。注意：由于使用JSON Path extractor ，必须将额外的库安装到 JMeter 主页才能运行脚本。在普通笔记本电脑上使用这些特定设置，您可以获得大约 10% 的 TxEnd 请求错误：

问题

尽管使用了悲观写锁，我仍然得到乐观锁定异常。是否有任何其他方法可以确保帐户的完整性，而无需为所有更新或同步方法创建任务执行队列？

UPD：任务执行器的工作被放置在另一个分支中。SpringThreadPoolTaskExecutor结合事务性任务解决了这个问题。

内部输入处理器也执行对钥匙的锁定和解锁作为悲观锁定。但是与悲观锁定相比，入口处理器更有效。这些to有什么区别？

我正在尝试为在不同 JBoss 节点中运行的 cron 作业实现某种信号量。我正在尝试使用数据库（Oracle 11g）作为锁定机制，使用一个表来同步不同节点中的 cron 作业。表很简单：

因此，当作业启动时，它会在表中搜索其 cronjobtype 的条目，并检查它是否已经在运行。如果不是，它将条目设置运行标志更新为真。第一个选择是通过 JPA CriteriaApi 使用 Hibernate 和悲观锁进行的。

所有这些操作都在一笔交易中完成。

当一个进程运行时，它进行的查询如下：

此警告没有问题，您可以看到先选择，然后选择更新，因此 Oracle 应该阻止该行上的其他选择操作。但这就是重点，查询没有被阻止，因此可以输入两个作业并毫无问题地进行选择和更新。锁不起作用，如果我们同时运行两个 cron 作业，我们可以看到它：

我已尝试在具有两个连接的 SQL 工具 (SQLWorkbenchJ) 上进行此选择以进行更新，并且该工具在此工具中运行良好。但是，如果我在 SQL 工具上选择更新并启动 cron 作业，它们不会被阻塞并且运行时不会出现问题。

我认为问题来自 JPA、Hibernate 或 Oracle 驱动程序，但我不确定。关于问题出在哪里的任何想法？我应该使用 anotehr 策略吗？提前致谢。

关于 Hibernate 3.3.2.ga 中可用的悲观锁定模式，我有两个问题：

1. 如果我使用 lockmode UPGRADE 锁定一组行，当您移出事务范围时，锁定是否会被释放？如果是，我们可以跨事务锁定解锁吗？

2. 对于以下场景，哪种 LockMode 会很有用

   • 线程 1，尝试获取锁并锁定一组行

   • 线程 2，尝试在同一组行（被线程 1 锁定）上获得锁，此时线程 2 得到一个异常，说行被锁定

   哪个是最好的悲观 LockMode？

我有以下类层次结构：

我正在尝试使用 hibernate 读取并锁定一个 ConcreteThing 实例，以便没有其他事务可以读取它LockOptions.UPGRADE。

现在的功能：

不起作用 - hibernate 不会生成“选择更新”语法，因此该对象没有悲观锁定

尽管：

正在工作 - 为刷新操作生成“选择更新”语法。

refresh() 和 get() 函数之间的区别在于 get() 函数使用左外连接来选择具体对象，而 refresh() 使用内连接来选择具体对象。

在悲观锁定的上下文中，这些连接之间有区别吗？

谢谢！

我有一种Rails 4.2.0使用悲观锁定来更改计数器的方法

我用Rspec 3.1这样的方式测试它

第一个change(foo, :counter)测试通过，但第二个change(foo.parent, :counter)失败，除非我同时注释掉lock!和parent.lock!

如果我像这样重写失败的测试，它会通过

为什么它不起作用expect{...}.to change？