ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ API SupportMessage Sequence

Post new topicReply to topic
Message Sequence View previous topic :: View next topic
Author Message
MQooch
PostPosted: Wed Dec 12, 2001 4:24 pm Post subject: Reply with quote

Novice

Joined: 11 Dec 2001
Posts: 12
Location: Randy

How do I keep messages from multiple sites form processing out of sequence?
Back to top
View user's profile Send private message
StefanSievert
PostPosted: Wed Dec 12, 2001 5:51 pm Post subject: Reply with quote

Partisan

Joined: 28 Oct 2001
Posts: 333
Location: San Francisco

Simple question, simple answer...

You can't. There is a very VERY restrictive set of conditions that have to be met to even maintain sequence of messages from a single producer and the general advice is to not rely on message sequence in an asynchronous messageing model. When messages come in from multiple producers, there is simply no way that you could possibly maintain sequence of processing. Just think of a scenario where app A produces a message 1ms after app B on another system. As both systems have their own network conenction to the consuming system, even a short delay in one of the network paths can put the A message ahead of the B message. I can't in my wildest dreams (and man, I have wild dreams!!!) envision an algorithm that can cover this requirement.
What determines sequence in your case? Message generation timestamp? The only way I can see is to insert each message in a database table, index it on the timestamp and process 'messages' off that table as they are returned from an SELECT ... ORDER BY SQL statement. But then, when do you assume that every message you want to process has arrived?
This subject makes up for discussion on a loooooong and cold winter night!
I hope I didn't miss your point completely.
Cheers,
Stefan

_________________
Stefan Sievert
IBM Certified * WebSphere MQ
Back to top
View user's profile Send private message
bduncan
PostPosted: Wed Dec 12, 2001 10:26 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Yeah, I can imagine using a database (visible to all your message producers) to do something like the following: You have a simple table with the primary key being an auto-increment integer. When you want to send a message, your application will insert a row into the table, and retrieve the auto-increment value that was placed in that row. This value would then be used as the CorrelId for the message it is going to send. The receiving side meanwhile will do MQGETs matching against CorrelId, increasing this value by 1 each time. This way, if a given message hasn't arrived, your receiving application will basically wait until it has arrived. There might be some issues with this approach, but I haven't thought it through yet...

_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
StefanSievert
PostPosted: Thu Dec 13, 2001 1:27 am Post subject: Reply with quote

Partisan

Joined: 28 Oct 2001
Posts: 333
Location: San Francisco

Hey Brandon,
that's something I thought of, too. But then again, as you said, this database table would need to be centrally available to all message producers and you'd need to make sure that you read the newly created number exclusively. You could provide a service based on MQSeries request/reply where, before putting the 'real' message, you request the next sequence number and then go with your approach. This service could be implemented using pure MQ techniques to maintain uniqueness of the seq.no. value.
I can imagine a lot of additional problems arising from such an approach and I would be more than interested to learn, what the business problem is that the original poster of the question is trying to solve.
Good night,
Stefan

_________________
Stefan Sievert
IBM Certified * MQSeries

[ This Message was edited by: StefanSievert on 2001-12-13 01:29 ]
Back to top
View user's profile Send private message
MQooch
PostPosted: Thu Dec 13, 2001 11:25 am Post subject: Reply with quote

Novice

Joined: 11 Dec 2001
Posts: 12
Location: Randy

I appreciate all the input!

I was curious if I'm simply updating my address from one site with a QMGR, and I always want the latest address update for the end application, could the application place information in the MQHDR that would maintain sequencing in the event that the message has several server possibilities.

Randy - New to MQSeries...but learning!
Back to top
View user's profile Send private message
bduncan
PostPosted: Thu Dec 13, 2001 4:13 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

MQSeries has functionality called Messaging Grouping, which allows you to create affinity between a logical group of messages, however, this requires the message producer to be a single application. In other words, you cannot have a group comprised of messages originating from different applications and/or queue managers. In your particular case, you may be able to leverage the fact that each message has a PUTTIME attribute. If all you care about is having the latest address, then you could do something like the following: on the target system (I'm assuming it's a database) set up your schema such that multiple addresses can be provided for a single entity. These addresses could have times associated with them. For instance, SAP does this automatically. If your company had an office for instance, and the address of the office changes, SAP will still retain the old address for data consistency purposes. You could do the same. In other words, every message that comes along with an address will be placed as a row in the table (you don't want them to overwrite each other) and when you query that table, you look for the address whose PUTTIME (another column in the table) is the most recent. This way, you are guaranteed to get the address that was most recently "PUT" in your MQ system.


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
StefanSievert
PostPosted: Thu Dec 13, 2001 5:49 pm Post subject: Reply with quote

Partisan

Joined: 28 Oct 2001
Posts: 333
Location: San Francisco

Brandon,
even if I am risking my head being chopped off: This will only work, if the time bases across the producing systems are synchronized. If you cannot make the simplification of taking the message reception time as the relevant timestamp, there is another technique that is commonly used. When querying the original row (for update) you can retrieve the timestamp of the last change of that row. If you pass this timestamp with your update request, your server application can determine if the database row has been modified in the meantime and reject the update request with an appropriate error message.
This can all be achieved in a single SQL statement, like: UPDATE ... WHERE last_mod = saved_timestamp. If this returns SQL code 100, the row must have been modified meanwhile.
Some applications also do a SELECT .. FOR UPDATE .. which locks the retrieved row(s) until a COMMIT/ROLLBACK. However, this approach may, in a distributed model, impose long database locks, which the DBA's usally are not too fond of, to put it mildly.

Do I make any sense here?
Cheers,
Stefan

_________________
Stefan Sievert
IBM Certified * WebSphere MQ
Back to top
View user's profile Send private message
bduncan
PostPosted: Fri Dec 14, 2001 12:32 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Stefan,
I actually prefer burning at the stake to lopping off heads
But yes, I had assumed that anyone attempting to use time stamps across multiple systems would have a time server somewhere that they were syncronizing against.
As for your approach, it looks sound, my only concern is that you don't want to always throw an error if the timestamps don't match. Assume that you have machine A and B trying to update the database. A creates an update message first, followed by B. These messages arrive on the database server in reverse order, B first, then A. The B update will occur, and because it is the most recent update, the database is now correct. However, the server will then try to process the message from A. The timestamps won't match, but because the timestamp in the database is in the future from A's timestamp, we know that the update is a more recent one than A's, so we should just disregard the message.
But yes, your approach requires less coding and probably less headache than using a time server...


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
StefanSievert
PostPosted: Fri Dec 14, 2001 2:53 pm Post subject: Reply with quote

Partisan

Joined: 28 Oct 2001
Posts: 333
Location: San Francisco

Brandon,
hmmm, burning at a stake, I've never thought of that...

You are absolutely right in what you said. And I am re-iterating what I said before: It all depends on the business requirements. If there is a user sitting at the other and, she might want to know if somebody updated the same record while she had it on her screen. If the producers are all server processes you might be able to just discard the older update. But then again, if process one updates the street address and process two the P.O. box, do you want to loose any of the updates? It all depends.
I am closing the subject and get myself ready and marinated for the stake...

Happy Holidays!
Stefan

_________________
Stefan Sievert
IBM Certified * MQSeries

[ This Message was edited by: StefanSievert on 2001-12-14 14:53 ]
Back to top
View user's profile Send private message
MQooch
PostPosted: Fri Dec 14, 2001 3:17 pm Post subject: Reply with quote

Novice

Joined: 11 Dec 2001
Posts: 12
Location: Randy

Thanks for all your input...I'm looking forward to studing my options.

Randy
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ API SupportMessage Sequence
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.