| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ and DB updates for sync |
« View previous topic :: View next topic » |
| Author |
Message
|
| John_peter |
 Posted: Wed Jun 30, 2004 10:07 pm Post subject: MQ and DB updates for sync |
 |
|
Novice
Joined: 10 May 2004
Posts: 22
|
How can I ensure that the following setup works with MQ
APP1 writes messages to a queue on QMGR1 for every db operation that it makes.DB is some application database. Example when it makes an insert it puts an 'insert' info as a message on the q, next it could put an 'update info' and so on.
Now ,APP2 on another queue on QMGR2 retireves this to replicate the same state on its db.
For this to work both the application and MQ must support this.
That is , I can make only one instance of the Application to service the q.
But when the message is tranmitted from qmgr1 to qmgr2 (DQM setup) , can i rely on the fact that the insert comes first and then the update (as initially put by APP1).The answer I guess is 'NO' coz of those number of conditions .
What is the solution?? Worse , when I cannot modify the application !!
Any thoughts??? |
|
| Back to top |
|
 |
| kman |
| Posted: Wed Jun 30, 2004 10:29 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
I may suggest using your own messageid.
Say first insert msgid is 1. Next insert would be 2. The receiving app then test for this messageid. If it receive 2 before 1, then he should return the message, and browse the queue for 1.
In fact, it could be selectively looking for msgid 1.
If receiving app already process msgid 3, then it can selectively get msgid 4. Or something like that.. you get the idea.
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 01, 2004 3:34 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Whether or not you can depend on the order of messages being preserved between two queue managers depends quite a bit on the nature of the network in between and the set up of your applications.
| Intercommunications Manual, Chapter 4, Channel Message Sequence Numbering wrote: |
If an application puts a sequence of messages to the same destination queue, those messages can be retrieved in sequence by a single application with a sequence of MQGET operations, if the following conditions are met:
All of the put requests were done from the same application.
All of the put requests were either from the same unit of work, or all the put requests were made outside of a unit of work.
The messages all have the same priority.
The messages all have the same persistence.
For remote queuing, the configuration is such that there can only be one path from the application making the put request, through its queue manager, through intercommunication, to the destination queue manager and the target queue.
The messages are not put to a dead-letter queue (for example, if a queue is temporarily full).
The application getting the message does not deliberately change the order of retrieval, for example by specifying a particular MsgId or CorrelId or by using message priorities.
Only one application is doing get operations to retrieve the messages from the destination queue. If this is not the case, these applications must be designed to get all the messages in each sequence put by a sending application.
Note:
Messages from other tasks and units of work may be interspersed with the sequence, even where the sequence was put from within a single unit of work.
If these conditions cannot be met, and the order of messages on the target queue is important, then the application can be coded to use its own message sequence number as part of the message to assure the order of the messages.
|
Kman - while using a MsgID as you suggest may not be a bad idea, your particular method would be vastly improved by ensuring that the receiving application gets messages in MsgID order, rather than in queue order, by "deliberatly changing the order of retrieval". This would also, to some extent, allow two instances of an application to process the same queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kman |
| Posted: Thu Jul 01, 2004 5:56 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
| Quote: |
| receiving application gets messages in MsgID order |
Come to think of it, you don't need to set your own messageid like my example. Messageid is in sequence and based on the system clock. In effect, you can just compare two messageid to know which one is earlier.
Like Jeff said, this allows for multiple instances of the receiving app. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 02, 2004 6:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kman wrote: |
Come to think of it, you don't need to set your own messageid like my example. Messageid is in sequence and based on the system clock. In effect, you can just compare two messageid to know which one is earlier.
Like Jeff said, this allows for multiple instances of the receiving app. |
I don't think you can rely on that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 03, 2004 6:50 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Provide only one way (no cluster) from qmgr1 to qmgr2
make transmition queue and app queue FIFO
have only a single thread service the APP queue.
That should ensure full FIFO.
Now you will have to think about volume. If the servicing app needs more then 24 hours to process a day's work....
Hope it helps some.
Anyway I would have thought you'd use DB mirroring at OS level for case like this! |
|
| 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
|
|
|
|
