如何用悲观锁定处理Hibernate中的“StaleObjectStateException”？

Question

编辑:在这种情况下，因为我使用了“版本”注释，所以我使用了乐观锁定，而不是悲观锁定。< br >如果我删除版本并因此禁用乐观锁定。悲观锁定会接管，性能会显著下降。< br >所以我想我必须忍受乐观锁定和偶尔的异常。有没有更好的解决办法？

原文：我目前通过ajp在apache 2.2负载均衡器中有多个Tomcat实例。后端系统处于Hibernate状态。该系统为多个用户和请求提供服务，对于请求，它会从用户帐户中扣除一个信用额度。

我使用hibernate的悲观锁定来管理信用扣减
我在日志中不断收到关于用户帐户对象的以下信息：

org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect)

法典

private boolean decUserAccountQuota(UserAccount userAccount, int creditDec) {

        if(userAccount.getBalance() <1) return false;
        String userName = userAccount.getUsername();
        Manager manager = getManager(userName);


        try{
            manager.beginTransaction();
            manager.refresh(userAccount, LockMode.UPGRADE); //this uses pessimistic locking, this calls sessionFactory.getCurrentSession().refresh();   
            userAccount.setBalance(userAccount.getBalance()-creditDec);
            manager.commitTransaction(); //this causes the Exception
        }catch(Exception exp){
            exp.printStackTrace();
            manager.rollbackTransaction();
            return false;
        }finally{
            manager.closeSession();
        }
        return true;
    }

问题：

1. 如何防止发生此异常。这里发生的事情是多个线程尝试更新相同的实体，一个线程成功，因此，当下一个线程提交数据时，它看到它已经被修改并最终抛出 StaleObjectStateException。但是，如果我已经使用了悲观锁定，那么异常怎么还会发生呢？
2. 在管理用户帐户信用系统的性能和完整性方面，是否有更好的方法？

Answer 1

在您的代码中，下面的行没有采用悲观锁，尽管您指定了它，因为您的数据库不支持 SELECT。对于更新 .

manager.refresh(userAccount, LockMode.UPGRADE); 

由于这个原因，hibernate使用一种称为LockMode的替代锁定模式。读取userAccount，它是基于实体中@Version属性的乐观锁定。

我搜索了是否有任何其他方法可以强制Hibernate对您的场景采取悲观锁定，但看起来它是不可能的。

回到您关于如何最小化或避免StaleObjectStateException的问题，我的想法如下：-

对用户帐户对象进行同步。虽然这似乎会影响性能，但只有当同一用户发出太多并发请求时才会发生这种情况。此外，牺牲一点性能来确保用户不需要抛出异常并重试将是理想的场景。

如果您找到了其他解决方案，请与我们分享。

Answer 2

您的Hibernate实体要么使用< code>@Version注释，要么定义< code >

如果您像您所描述的那样显式地使用悲观锁定，那么删除上面的内容应该可以解决您的问题。

更多信息在这里