| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Which design to choose? So |
« View previous topic :: View next topic » |
| Author |
Message
|
| optimist |
 Posted: Tue Nov 20, 2012 6:36 am Post subject: Which design to choose? So |
 |
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
We have a need to store the "last batch run time" somewhere and use it to pick up the updated records from a partner system during the next batch run. We wanted to use a database table to capture this, but currently for reasons that I do not want to get into, we do not have access to one in the integration layer. So, it was decided to use a "mq queue" to keep track of the last updated timestamp.
The flow that reads the "last timestamp message" from mq performs couple of transactions in other partner systems (non-XA), before finally inserting a new "last timestamp message" on to the queue.
It looks like, as long as the message is picked up from the queue and a new message is inserted back into the same queue within a transaction, we should be good. (of course, the peace of mind comes from the guarantee that we never have to worry about losing persistent messages in mq as long as we use transactional moves).
However, wondering if there is anything to gain from performing the transaction (of removing the current timestamp message and replacing it with a new one) the following way:
Browse the current message from the queue using MqGet node in browse mode
Perform the updates in partner systems
Now, use an MqGet node to transactionally get the current message and insert a new timestamp message on the queue
Other than this method being a bit more atomic, is there anything we gain from it? Thoughts?
(btw, multiple updates to partner systems are fine and there is no-need for 2PC)
Thanks. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Nov 20, 2012 6:38 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
MQ is not a database and should not be used as one. Other options are: MySQL, Singleton, flat file.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Nov 20, 2012 6:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ is not a database.
Broker itself uses MQ to hold state information about collections, aggregations, manage timeouts and other tasks.
You should consider some operational aspects of this system... if you leave the message sitting on the queue under a browse cursor, is that easier or harder to troubleshoot from an operational frame than if you consume it transactionally?
Maybe it doesn't make a difference, but you should consider it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 20, 2012 8:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you need also to consider whether your method is threadsafe...
How do you handle multiple instances of the flow?
What happens if 2 instances attempt to update at the same time?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| optimist |
| Posted: Wed Nov 21, 2012 5:34 am Post subject: Thanks |
|
|
Apprentice
Joined: 18 Nov 2010
Posts: 33
|
Thanks for all your responses. I am not hearing anything that calls for browse in this case and that is exactly what i wanted to know.
fjb_saber: Good point. However, the message with data that kicks off the flow comes in once every hour or so and there will not be a case where we will be running more than one instance of the flow. So, we should be good.
Thanks. |
|
| 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
|
|
|
|
