This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am working on enhancement of an old J2EE application which communicates with Mainframes using MQ.
After sending the data to MQ request Queue it waits for the reply on the response queue. The wait period is 2 mins.
After that it shows an popup to user that there is problem processing your request, but on the mainframes side the request was processed and data is updated in their database. So our database is out of sync and also the message is stuck in the queue forever.
How can I enhance it so that our database is updated properly?
OK, if I'm understanding this correctly the J2EE sending a message to a mainframe application, and expecting the mainframe to send a second (response) message back to it. That message never arrives, and yet the mainframe has received the request message and processed it successfully. It seems unlikely to me that the response message is "stuck" in the queue. Much more likely is that the mainframe app just isn't sending one. Is that possible?
Joined: May 30, 2007
Thanks for the response.
The scenario is like this:
1. J2EE app send a message on request Q for Mainframe app and wait for the response on the response Q for 2 mins.
2. When mainframe app completes the message processing it writes the response on the response Q.
3. But if Mainframe app takes more than 2 mins to write the message on the response, the J2EE app timesout and shows a popup error on the screen to the user.
4. Now if the mainframe writes the message on the response Q, it get stuck for ever.
I am having the same kind of problem, there are times where the response from our backend host sending to our web got stuck in the queue(due to unknown reasons) and when the communication is back into normal the stucked message will be sent to the web and the subsequent request (not the previous request) is getting the stucked response which is meant for the previous request.