java - Hibernate 是否会在死锁时自动重启事务？

Question

关于这个话题已经有很多文章了:

• Restarting transaction in MySQL after deadlock
• Deadlock found when trying to get lock; try restarting transaction : @RetryTransaction
• MySQL JDBC: Is there an option for automatic retry after InnoDB deadlock?
• Working around MySQL error "Deadlock found when trying to get lock; try restarting transaction"
• ... 更多

我发现最后接受的答案特别有趣:

If you are using InnoDB or any row-level transactional RDBMS, then it is possible that any write transaction can cause a deadlock, even in perfectly normal situations. Larger tables, larger writes, and long transaction blocks will often increase the likelihood of deadlocks occurring. In your situation, it's probably a combination of these.

这意味着我们永远无法阻止它们，只能对付它们。真的吗？我想知道您是否可以在有 1000 人在线调用写数据库操作的网站上防止死锁。

谷歌搜索该主题没有得到任何有趣的结果。我找到的唯一一个是这个 ( http://www.coderanch.com/t/415119/ORM/databases/Deadlock-problems-Hibernate-Spring-MS ):

public class RestartTransactionAdviser implements MethodInterceptor {
    private static Logger log = Logger.getLogger(RestartTransactionAdviser.class);

    public Object invoke(MethodInvocation invocation) throws Throwable {
        return restart(invocation, 1);
    }

    private Object restart(MethodInvocation invocation, int attempt) throws Throwable {
        Object rval = null;
        try {
            rval = invocation.proceed();
        } catch (Exception e) {
            Throwable thr = ExceptionUtils.getRootCause(e);
            if (thr == null) {
                throw e;
            }

            if (StringUtils.contains(thr.getMessage(), "deadlock") || StringUtils.contains(thr.getMessage(), "try restarting transaction") || StringUtils.contains(thr.getMessage(),
                    "failed to resume the transaction")) {
                if (attempt > 300) {
                    throw e;
                }
                int timeout = RandomUtils.nextInt(2000);
                log.warn("Transaction rolled back. Restarting transaction.");
                log.debug("Spleep for " + timeout);
                log.debug("Restarting transaction: invocation=[" + invocation + "], attempt=[" + attempt + "]");
                Thread.sleep(timeout);
                attempt++;
                return restart(invocation, attempt);
            } else {
                throw e;
            }
        }
        return rval;
    }
}

另一方面，我严重怀疑这种解决方案的质量。您能否详细说明并解释什么是最好的死锁处理方式？如何处理银行和企业应用中的死锁？

Answer 1

Hibernate session 需要一个 transaction write-behind一级缓存。这使您能够将更改推迟到最后负责的时刻，从而减少锁定获取间隔(甚至发生在 READ_COMMITTED isolation level 中)。

这意味着您必须尽量减少所有交易时间，我可以推荐使用 FlexyPool为了这样的努力。您需要确保所有事务都尽可能短，以减少锁定间隔，从而提高可伸缩性。

锁定引入串行操作，根据Amdahl's law ，可扩展性与总串行操作分数成反比。

我的建议是首先着手减少交易间隔。索引将减少查询时间。 ORM 可能会生成糟糕的查询，因此请确保您的 integration tests verify expected queries against actual executed ones .

类似p6spy 的工具非常方便地为您的查询计时，因此请确保您也使用它。

当所有事务都尽可能短并且您仍然需要更多并发时，您可以转向水平可扩展性。您可以首先从同步主从复制策略开始，将读取重定向到节点从属节点，同时保留主节点进行写入事务。