I suspect that the browsed message and MsgId stored in a DB is a part of a larger business process; and answers the question 'where was I?' if the flow is interrupted.
You got it right bruce.. That's the exact reason for this approach. I need to start processing the same message in case of interruption.
Vitor wrote:
So if you're only browsing 1 message (and then storing it in a database), under what circumstances would you not browse the same message off post-crash? How could you get a different message and why would this matter to you if you did, given that the messages have no affinity? What advantage does the database give you and what will you do if the application is fine but the database is down / running slow?
All the messages are browsed and stored in an internal queue. Post-crash it may happen that there are more messages that landed in the MQ during crash. In such a case how will I browse the same message that I was processing before crash as this may not be the first message on the queue that i started processing since an internal priority is being assigned?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum