| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Application design issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| wongpcl |
 Posted: Wed Dec 11, 2002 10:53 pm Post subject: Application design issue |
 |
|
Novice
Joined: 09 Jan 2002
Posts: 23
|
Hi,
We're designing a MQSeries application. The MQSeries Servers V5.3 are installed in 2 AIX Server machines. A pair of sender/receiver channel is setup between these 2 queue managers.
For simplicity, "Machine A" has a queue manager called "QMA" and a program called "Program A". In "Machine B" there is a queue manager called "QMB" and a program called "Program B".
In the "Machine A", the "Program A" will send a message to a queue in "QMB" and then it will get wait for 30 seconds on a local queue for response. When the message is arrived to the queue on "QMB", it will trigger the "Program B" to update the info to a database. When the update is finished, the "Program B" will send a response to a response queue in "QMA" to signify the database update is successful. If the "Program A" can't get the response message within the 30 seconds, it will treat it as failure and will retry to send the message again.
We have an issue if the message is successfully updated to the database but the response message is failed to send to the response queue within the time limit, the "Program A" will retry, which may cause the same data to be updated twice in the database.
How can I solve it? The requirement of the 30 seconds response time is fixed.
Thanks, |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Thu Dec 12, 2002 12:21 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
There are different possibilities, from which I will suggest:
0)
Why use MQ Series if you want synchronous work?
1)
Don't retry after 30 seconds.
If you want assured delivery, mark the message as persistent. After 30 seconds, you can say that the message was not processed yet but eventually you are sure that it will be processed.
I understand this is a technical answer and might not be acceptable from an applicative point of view.
But by the way if you did not receive a reply within 30 seconds, what makes you believe that by sending again, the new message will succeed? What happened to he initial message?
2)
Have your application be able to determine whether the database update has already been performed or not. Your application is then more robust, it can handle message replay safely.
But again, what makes you believe that replaying the message will work better?
And if you have a requirement of 30 seconds response time, why can you send a second message after 30 seconds and wait again?
3)
This third option is more an application design option that I have already met: a combination of quick response time, and at the same time complex processing to be performed behind.
The idea is that program A immediately records the client request in the database, then the request gets its status updated when the async processing is performed on it. The advantage is that the client gets an immediate answer, and can follow on-line the evolution of its request. (like you would follow the workflow of an order processing).
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
