Spring Framework
  1. Spring Framework
  2. SPR-5890

Suggestion for Deadlock-Retrying in @Transactional annotation

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2 RC2
    • Fix Version/s: None
    • Component/s: Transaction
    • Labels:
      None
    • Last commented by a User:
      false

      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.

        Activity

        Hide
        Gert-Jan Schouten added a comment -

        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)

        Show
        Gert-Jan Schouten added a comment - 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)
        Hide
        Eric Pederson added a comment -

        I would remove the "deadlock" from the parameter names since you may be facing other circumstances in which you want to retry.

        Show
        Eric Pederson added a comment - I would remove the "deadlock" from the parameter names since you may be facing other circumstances in which you want to retry.
        Hide
        Rossen Stoyanchev added a comment -

        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.

        Show
        Rossen Stoyanchev added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Gert-Jan Schouten
            Last updater:
            Trevor Marshall
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 44 weeks, 3 days ago