Hibernate - Pessimistic_Write LockMode在Oracle中不按预期工作

Question

Hibernate 4.2 Pessimistic_Write锁在Oracle中没有正常运行，而对于PostgreSQL和Microsoft，它正在按预期工作。有什么想法吗？

让我再解释一下。

我在日志中找到了StaleObjectException。

StaleObjectException：-“行被另一个事务更新或删除(或未保存的值映射不正确) hibernate”

Hibernate无法在Oracle上保存Pessimistic_Write LockMode，但在其他数据库中，它工作得很好。这是以并发模式(多线程环境)访问的。

代码：-

private static final String query1= "select e from EMPLOYEE e join e.addressList address where address in (:addressList) order by e.streetName,e.createdOn";

Query query = getSession().createQuery(query1).setLockOptions(new LockOptions(LockMode.PESSIMISTIC_WRITE));

Answer 1

问题在于Hibernate如何处理Oracle中的悲观写锁。每当您执行悲观锁以锁定一行时，其他数据库都会触发单个查询以获得该行并锁定该行，以便其他事务无法修改加载的记录。在Oracle的情况下，Hibernate对此进行了不同的处理。对于Oracle，它发出两个查询--一个用于加载记录，另一个用于使用“SELECT FOR UPDATE”子句锁定加载的记录。现在的问题是，Hibernate为Oracle生成的两个sql语句不是原子的，也不是由锁控制的，因此在内部，我们触发的单个查询转化为两个查询。因为这两个查询不是原子的，如果两个线程触发我们的查询，那么这两个查询都加载相同的记录而不锁定。在此之后，第一个线程获取锁(第二个线程已经加载)并更新它。现在，当第二个线程试图获取它已经加载的记录的锁时，当第一个线程更新它时，它会检测到一个更改，从而抛出一个陈旧的对象异常。因为这是核心Hibernate平台的一个问题，所以我们无法修复这个缺陷的根本原因。

我们找到了一个解决办法。为了解决这个问题，我们引入了一个解决办法，在触发实际查询之前，通过悲观写锁定另一个表。这将确保线程锁定行为正确工作，而牺牲了响应时间的小幅增加(几毫秒)。