prevent MQ listener service from moving message into DLQueue

How to prevent MQ listener service from moving message into Dead Letter queue

We have following scenario
(Messages in the queue are related, in case of error message should remain in the same queue, but messages are getting moved into dead letter queue, we want message to roll back to same queue and retried for ever).

I have tried following

Notification Listener Service

  1. webSphere mq notification created on sync Listener and webSphere transactional connection.
    Flow service performing JMS Put
  2. Listener service invokes JMS XA put. (separate flow service with jms put, I am throwing exception , and after catch I am throwing exception for retry - this service uses explicit transaction).
    Notification Listener Service (I have tried implicit and explicit transaction. )
  3. In case of exception I am rolling back the transaction and throwing exception for retry.

Observed behavior :
When I invoke, message is not rolled back into the queue
(I have installed mq explorer and observed messages are not rolled back into the queue)

Only way I can achieve above is by adding following on listener notification service

  1. Get retryCount
  2. Invoke rollbackTransaction
  3. Set Max attempts on the service as n
  4. When retryCount = n, invoke suspendListener and disable connection

Once listener and connection are disabled, message is rolled back to the same queue. I can observe backout threshold in mq explorer gets incremented by 1.
But I get following error message on IS logs:
2010-02-09 10:58:32 EST [SCC.0126.0201I] SCC ConnectionManager pool
_XATransaction stopped
2010-02-09 10:58:32 EST [SCC.0126.0101E] An error occurred while attempting to release connection krJewelryTax

Note: Although Listener is configured with backout threshold = n , If I perform roll back on notification service, backout threshold number is not incremented on mq.

Did you have the rollbackTransaction service in the Catch block and at the end Exit (On Failure) step in place?

Catch Sequence
pub.flow:getLastError (Must be a local transaction)
Exit step (On FAILURE) – This is important for data rollback

Please test the above condition also.