| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| One-way datagram + unit of work design question |
« View previous topic :: View next topic » |
| Author |
Message
|
| aq |
 Posted: Thu Aug 08, 2002 12:16 am Post subject: One-way datagram + unit of work design question |
 |
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
Hi, I would have design question for all of you experts.
The situation would be the following:
1. MQS sendeing end is sending one-way datagram messages about 200 - 800 per day.
2. On the receiver end there is multithreaded receiver service that would read message from the queue and write it's information to database, but there is risk that the database might be offline or in error state. When the receiver application cannot write the data that message contained to database, the message should be somehow be stored somewhere or be available for latertime to be processed when database come's back online.
What would be the best recommendation to do such system, we have though that we could make unit of work for receiver application, when it reads the message from queue and if the database write failes just back out the unit of work and the message would be remaining on queue, until it can be written again to database. What you think ?
regards,
aq |
|
| Back to top |
|
 |
| jhalstead |
| Posted: Thu Aug 08, 2002 1:43 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
This seems like the way I'd tackle it (I'm assuming there is an MQSeries Server on the DB host...
1 Connect to QM, COnnect to DB & Open MQ Queues.
2 Get from queue (WAIT)
3 Insert to DB
4 Commit to DB & MQ or Backout based on DB return code.
The method you described would be largely ok, however if the case of crahses / hardware failure the time between issuing the DB commit and MQ commit leaves a small window of opertunity for inconsistent states to arise.
Use MQ to co-ordinate transaction or use another queue to assist in your application surviving a MQ/DB/Hardware failure. These will increase resource consumption - however you're talking about very small no of messages!
Good Luck!
Jamie |
|
| Back to top |
|
|
| kirani |
| Posted: Thu Aug 08, 2002 8:15 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Aq,
As Jamie said, I would prefer to use 2-phase commit here by configuring Queue manager to act as Transaction coordinator and DB manager will participate into global transaction. This will perform slower than the other solution, but error handling is more robust here. This will take care of application/hardware crash. Please note that all database products are not supported for coordinated transaction by MQSeries.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| aq |
| Posted: Thu Aug 08, 2002 9:59 pm Post subject: |
|
|
Apprentice
Joined: 20 Dec 2001
Posts: 47
|
Thank you for these advices Jamie and Kiran !
As you succested, the MQ coordinated (2 phase) transaction sound as the solution that would work at this case, and it doesn't matter even if it brings little bit slowness as Kiran mentioned because the quantity of messages per day is currently quite small.
regards,
aq |
|
| 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
|
|
|
|
