Hi Om
You seem to be looking for some capabilities which would be impossible in combination.
In order to achieve rollback on pod termination, you would need to configure your MQGET operation under syncpoint. If the messages are sufficiently important to be retried on pod failure, then presumably they would be persistent too.
Client Readahead is disabled for GETs under syncpoint and for persistent messages, so you won't get both.
The REST interface does support browse, but doesn't implement locks, so your other instances will also be able to see the messages. The REST interface does not support separation of the GET and the commit, so you won't get rollback on pod failure.
I don't think you can achieve what you want with MQ.
I would be surprised to find any messaging system that could implement read ahead and reliable commit processing against persistent messages.
If you remove the requirement for read ahead, then MQ using the MQI can implement your commit and rollback requirement, including preventing other instances from seeing the message. There is an unsupported nodeJS library for MQ which includes Commit and Rollback functionality, so I would assume that you could use that providing the lack of support is not an issue. See .
https://github.com/ibm-messaging/mq-mqi-nodejsAs far as I'm aware you can't run .NET on k8s with normal pods. I think you will need to rewrite your code to a suitable pod hostable language (like javascript running on nodeJS). I don't know about running with Windows based pods.
------------------------------
Neil Casey
Senior Consultant
Syntegrity Solutions
Melbourne, Victoria
IBM Champion (Cloud) 2019-20
+61 (0) 414 615 334
------------------------------