java - Hibernate deadlocking transactions - automatic restarts? -

java - Hibernate deadlocking transactions - automatic restarts? -

there has been lot written topic:

restarting transaction in mysql after deadlock deadlock found when trying lock; seek restarting transaction : @retrytransaction mysql jdbc: there alternative automatic retry after innodb deadlock? working around mysql error "deadlock found when trying lock; seek restarting transaction" ... many more

i find particularly interesting lastly accepted answer:

if using innodb or row-level transactional rdbms, possible write transaction can cause deadlock, in normal situations. larger tables, larger writes, , long transaction blocks increment likelihood of deadlocks occurring. in situation, it's combination of these.

that mean can never prevent them, deal them. true? wonder if can ever prevent deadlocks on website 1000 people online invoke write db operations.

googling on topic not interesting results. 1 found (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 { homecoming restart(invocation, 1); } private object restart(methodinvocation invocation, int attempt) throws throwable { object rval = null; seek { rval = invocation.proceed(); } grab (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 resume transaction")) { if (attempt > 300) { throw e; } int timeout = randomutils.nextint(2000); log.warn("transaction rolled back. restarting transaction."); log.debug("spleep " + timeout); log.debug("restarting transaction: invocation=[" + invocation + "], attempt=[" + effort + "]"); thread.sleep(timeout); attempt++; homecoming restart(invocation, attempt); } else { throw e; } } homecoming rval; } }

on other hand uncertainty quality of such solution. can please elaborate , explain best handling of deadlocks? how deal deadlocks in banks , enterprise applications?

the hibernate session entails transaction write-behind first level cache. enables post-pone changes lastly responsible moment, hence reducing lock acquisition intervals (happening in read_committed isolation level).

it means have minimize transaction time , can recommend using flexypool such endeavor. need create sure transactions short possible, cut down locking intervals improve scalability.

locking introduces serial operations, , according amdahl's law, scalability inverse proportional total serial operations fraction.

my advice first work on reducing transaction intervals. indexing cut down query times. orms might generate awful queries create sure integration tests verify expected queries against actual executed ones.

a tool p6spy handy timing queries create sure utilize too.

when transactions short possible , still need more concurrency, can move horizontal scalability. can first start synchronous master-slave replication strategy , redirect reads node slave while keeping master write transactions.

java mysql spring hibernate transactions