jms-spec
  1. jms-spec
  2. JMS_SPEC-117

Specifying redelivery behaviour when a JMS MDB performs rollback

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1, 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      It may be helpful if the spec defined what should happen if a JMS MDB receives a message and then rolls back the transaction, typically because setRollbackOnly has been called. If the rollback is caused by a system error (such as a database failure) then the same message might be redelivered and rolled back repeatedly.

      Possible behaviour that might be required is:

      • A delay before the message is redelivered - perhaps increasing as the number of redelivery attempts increases
      • A maximum number of consecutive rollbacks after which the message will be delivered to a dead-message queue

      No doubt there are other possibilities.

      It would of course be necessary to allow this behaviour to be configured, perhaps using activation properties.

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment - - edited

          Comment from colleague TB:

          I thought there were already some JIRAs in this area. As time permits, can you comment on whether the following related functionality is covered?

          • An equivalent to "setRollbackOnly" for non-TX MDB would be nice. E.g., a way to force redelivery without throwing
          • An equivalent to this JIRA issue for the MDB non-TX case (or extend the current JIRA).
          • An equivalent to this JIRA issue for pure JMS clients (or extend the current JIRA).

          As for the latter, there are trade-offs between implementing rollback/recover side-effects at the JMS layer or the MDB layer. It looks like it would be helpful to consider both layers at the same time when spec'ing out this area.

          JMS layer poison-messaging-handling can preserve the message-id and time-stamp, can treat both expired and redelivered messages using the same mechanism, can move the problem message to a new destination with optimal efficiency, and can move the message "exactly-once" to the error destination without requiring the client to be transactional. The MDB layer, on the other hand, can forward the message with a helpful "rollback reason" attached as a property, and can forward the failed message to any destination - not just destinations known to the original provider.

          Show
          Nigel Deakin added a comment - - edited Comment from colleague TB: I thought there were already some JIRAs in this area. As time permits, can you comment on whether the following related functionality is covered? An equivalent to "setRollbackOnly" for non-TX MDB would be nice. E.g., a way to force redelivery without throwing An equivalent to this JIRA issue for the MDB non-TX case (or extend the current JIRA). An equivalent to this JIRA issue for pure JMS clients (or extend the current JIRA). As for the latter, there are trade-offs between implementing rollback/recover side-effects at the JMS layer or the MDB layer. It looks like it would be helpful to consider both layers at the same time when spec'ing out this area. JMS layer poison-messaging-handling can preserve the message-id and time-stamp, can treat both expired and redelivered messages using the same mechanism, can move the problem message to a new destination with optimal efficiency, and can move the message "exactly-once" to the error destination without requiring the client to be transactional. The MDB layer, on the other hand, can forward the message with a helpful "rollback reason" attached as a property, and can forward the failed message to any destination - not just destinations known to the original provider.

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              Nigel Deakin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: