0

I have a JMS consumer that processes transactions against a third-party service.

When there is an exception calling this third party service e.g a java.net.ConnectException. I would like this message to be redelivered by the queue.

Redelivering can be done in two obvious approaches.

  1. Roll-back the transaction context: The queue redelivers the message but the JPA transaction is rolled back (however, I want the db to have a record of the transaction to prevent duplicate messages if any).

  2. Resend the message from the consumer with a redelivery time: The transaction context is preserved (record is saved in the db).

Are there any performance issues with re-sending messages from the consumer into the queue as opposed to not acknowledging them?

F.O.O
  • 4,730
  • 4
  • 24
  • 34
  • You would need to implement some kind of 'ReplayServer' with your DB. Can't you just re-request and resend the missing messages ? – Axel Podehl Jul 16 '18 at 07:15

1 Answers1

2

It's more reliable to rollback.

You should simply start a new transaction for the DB update instead of synchronizing it with the JMS transaction, so the DB transaction commits even if the JMS transaction rolls back.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • one concern: i do quite a bit of db saves and creating a new transaction for each update seems to increase load on the db connection pool as opposed to having one transaction that gracefully terminates. – F.O.O Jul 12 '18 at 15:28