Does Hibernate automatically restart transactions upon deadlocking?

Question

There has been a lot written about this topic:

I find particularly interesting the last accepted answer:

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.

That would mean that we can never prevent them, but only to deal with them. Is that true? I wonder if you can ever prevent deadlocks on website with 1000 people online who invoke write DB operations.

Googling over the topic does not get any interesting results. Only one I found was this (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;
    }
}

On the other hand I seriously doubt quality of such solution. Can you please elaborate and explain what would be the best handling of deadlocks? How do deal with deadlocks in banks and enterprise applications?

And what are your doubts with such a solution? It is AOP catching exceptions and retrying in certain situations. Although 300 retries might be a bit steep. Spring also has a small project, [Spring Retry](https://github.com/spring-projects/spring-retry) (also used by Spring Integration and Spring Batch for just this kind of logic). — M. Deinum, Oct 21 '14 at 06:16
And is it really the best way to try to restart the transactions? Isn't really there a way to prevent them in heavy-load databases? — Vojtěch, Oct 21 '14 at 15:08
And what is wrong with a retry. You could try and prevent them by isolating database but that way your application will crawl... — M. Deinum, Oct 21 '14 at 17:54
Related question: http://stackoverflow.com/questions/26844162/methodinterceptor-for-hibernate-transactions — Vojtěch, Nov 11 '14 at 08:08

Vlad Mihalcea · Accepted Answer · 2018-01-04T18:56:48.587

The Hibernate Session entails a transaction write-behind first level cache. This enables you to post-pone changes up to the last responsible moment, therefore reducing lock acquisition intervals (happening even in READ_COMMITTED isolation level).

It means you have to minimize all transaction time and I can recommend using FlexyPool for such endeavor. You need to make sure all transactions are as short as possible, to reduce locking intervals so to improve scalability.

Locking introduces serial operations, and according to Amdahl's law, scalability is inverse proportional to the total serial operations fraction.

My advice is to first work on reducing transaction intervals. Indexing will reduce query times. ORMs might generate awful queries so make sure your integration tests verify expected queries against actual executed ones.

A tool like p6spy is very handy for timing your queries so make sure you use it too.

When all transactions are as short as possible and you still need more concurrency, you can move to horizontal scalability. You can first start with a synchronous master-slave replication strategy and redirect reads to the node slave while keeping the master for write transactions.

Does Hibernate automatically restart transactions upon deadlocking?

1 Answers1