| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| message sequencing rant |
« View previous topic :: View next topic » |
| Author |
Message
|
| gwlfng |
 Posted: Sun Feb 02, 2003 8:07 pm Post subject: message sequencing rant |
 |
|
Newbie
Joined: 13 Nov 2002
Posts: 8
Location: Boston
|
This is kind of in the "rant" category, perhaps more about messaging in general than MQ in particular.
I know that MQSeries guarantees message delivery (given persistent messages, etc), but does not guarantee the sequencing of multiple messages. I think you can get close by sending to a single queue with two queue managers using distributed queuing and running a single channel pair and uniform message priority. But with clustering it can really get wild.
The thing that bugs me is that I can't think of many applications that don't rely on some semblence of sequencing.
I'm not talking about message affinities in the sense of multiple related messages sent out in one unit of work. Say a user gets into an application and adds a "customer", then very quickly changes the same customer. The app sends messages about these events to another app on another platform, but say the update arrives before the add. Or, two users change the same customer at almost the same time, but the second change arrives first.
Are people writing lots of elaborate code on the receiving end to suspend/retry out of sequence messages? |
|
| Back to top |
|
 |
| Troilus |
| Posted: Sun Feb 02, 2003 11:06 pm Post subject: |
|
|
Apprentice
Joined: 12 Jul 2002
Posts: 28
Location: Belgium
|
Short answer : yes.
If you want to take advantage of Websphere MQ, or of Asynchronuous messagging in general, you must also learn to live with the disadvantages. Time-independence of the 'update generating' and 'update processing' applications offers a lot of flexibility, but does need considerations like the ones in your example. No one says message oriented middleware is the answer for everything. You should compare remote DB access with MOM and decide what's best in your case. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Sun Feb 02, 2003 11:53 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I agree with Troilus that an asynchronous application will not facilitate your application development.
I just want to contribute with some thoughts on the subject (this is a forum open to discussion isn't it?)
I would like to moderate your examples. You have to make a clear difference between synchronous/interactive/continuous/real-time applications versus real asynchronous applications.
With synchronous applications, there is most of the time some sort of request/reply dialog implemented over MQ, which makes me think that most people use an asynchronous middleware to write synchronous applications. Your example is a perfect illustration: how the hell can you send an update request for a customer that does not exist? What customer identification do you use in the update request? I simply do not think that this example is ever implemented the way you describe it.
We cannot say that an application is pure synchronous or pure asynchronous. For example in order processing, there is some interactive part to retrieve catalogs, and order details. But when orders are sent they can be processed in any sequence (I think).
Even with interactive applications using remote data access, people need to implement sequence logic. The usual example is the "lost update" in a database: two users retrive the same customer identification, and both perform an update on the same customer. The first update will be overriden by the second one if you do not have some sort of concurrent update detection mechanism (such as a last update timestamp).
These were my two eurocents 
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| gwlfng |
| Posted: Mon Feb 03, 2003 8:46 pm Post subject: |
|
|
Newbie
Joined: 13 Nov 2002
Posts: 8
Location: Boston
|
Thanks, I appreciate the thoughts and comments. I pretty much agree with everything said.
Just for clarification of the example, I was thinking of a pure synchronous, fire and forget, data propogation application where messages trickle operational information to a data warehouse. MQ is nice because it insulates the operational app from the network ups and downs, and keeps cross platform updates out of it's units of work. Being able to count on the sequence of the flow of updates would make it simpler on the receiving end, but it is still worth the extra complication. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Mon Feb 03, 2003 10:56 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Ah OK I understand your example.
In the case of replication we use a mechanism of last update timestamp. We only update the database if the message timestamp is greater than the one already in the database. If two messages T1 and T2 become out of sequence, T2 will be processed and update the database, and T1 will be ignored if it comes after T2.
So you were right at the beginning, you need to implement some logic in your application: MQ does not solve the problem!
Nice to be part of this interesting discussion
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
|
|
|
|
