Gert-Jan Schouten opened SPR-5890 and commented
If you use locking on databases, you always have to provide for the situation that your transaction rolls backe because of being selected as a deadlock victim.
The usual behaviour to deal with this situation is to retry some time later (e.g. 1s).
I think this is something that could be handled by a framework like Spring. If the method that has the transaction facade does not have any side effects (like modifying the input parameters or modifying some entity that is not part of the transaction), a proxy (or perhaps the TransactionInterceptor) could just call the same method again and again - until the transaction succeeds, rolls back because of another reason than deadlock victim, or a configurable timeout elapses.
Affects: 1.2 RC2
1 votes, 1 watchers
Comment From: spring-projects-issues
Gert-Jan Schouten commented
This is a clone from http://jira.springframework.org/browse/SPR-911, because that one was really old...
I suggest some additional properties for the @Transactional annotation:
-deadlockRetryAttempts: The number of attempts a deadlock is retried, before throwing an Exception
-deadlockRetryInterval: The number of milliseconds between retries
-deadlockExceptionClass: Since the specific deadlock Exception is dependent upon the JDBC-driver, you can specify the Exception that represents a deadlock, this does not have to be the "outer" Exception, but it can be in the cause-hierarchy too.
A complete example of such an annotation would be the following:
@Transactional(
isolation=Isolation.SERIALIZABLE,
propagation=Propagation.REQUIRED,
readOnly=false,
deadlockRetryAttempts=5,
deadlockRetryInterval=1000,
deadlockExceptionClass=WhatEverException.class)
Comment From: spring-projects-issues
Eric Pederson commented
I would remove the "deadlock" from the parameter names since you may be facing other circumstances in which you want to retry.
Comment From: spring-projects-issues
Rossen Stoyanchev commented
This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.
There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.
If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.
We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.
Comment From: roma2341
In 2023 year, nobody answered what to do with these deadlock issues.. should we write a custom deadlock aspect like this? https://gist.github.com/l0co/71506c1f2e7c075589b5 This solution is ugly because can lead to unpredictable results, but finding and fixing deadlocks is too complex task to do.