Details

Description

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.

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.

Gert-Jan Schouten
added a comment - 02/Jul/09 8:08 AM 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)

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.

Rossen Stoyanchev
added a comment - 18/Jun/12 12:44 PM
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.