| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Routing Table - Using Database vs MQ Browse |
« View previous topic :: View next topic » |
| Author |
Message
|
| ayanc |
 Posted: Thu Apr 15, 2010 12:36 am Post subject: Routing Table - Using Database vs MQ Browse |
 |
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi,
We currently have a proprietary solution of routing messages to different queues based on Custom Node that reads data from property file.
We are now planning to move away from proprietary solution into a more generic solution and currently looking at the following two options:
1. Configure routing details into a Database. For each message there would be a database lookup to obtain the queue information.
2. Place a single property file type message in a Queue and use MQGet node to browse the data. So for every message the file could be loaded into Environment tree and the queue details obtained.
Things to consider: Multiple message flows would be reading this data at a single point of time. Addition of data (rows) in a database could be much easier than replacing the file in MQ.
Option 1 is a secure, tried and tested approach. I am keen to know about option 2. I have a feeling that option 2 could have better performance than option 1.
Any thoughts / suggestions on pros and cons? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Thu Apr 15, 2010 1:56 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
My 2p worth is
Use a Database every time. Far more Auditable, repeatable etc.
Also easy to change the Q names from Dev to UAT to Prod if needed.
 For getting rid of properties files.
Yeah, I know I'm a 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| paranoid221 |
| Posted: Thu Apr 15, 2010 2:09 am Post subject: |
|
|
Centurion
Joined: 03 Apr 2006
Posts: 101
Location: USA
|
Database route would be the way to go.
However I'm rather alarmed by this comment of yours:
| Quote: |
| 1. Configure routing details into a Database. For each message there would be a database lookup to obtain the queue information. |
You don't want to go to the database for each message to obtain what you need. If the data you are storing there is fairly static, I'd suggest a caching approach inside your flow to persist that data in memory for much faster lookups. At the same time however, if you are storing large amounts of data in your database tables, you don't want to maintain a large enough cache either. In that scenario, you could only cache information that you have previously pulled for other transactions that you've already processed. Set a threshold inside your flow on how many records you want to store in cache and based on that you could keep the most recent ones and discard the rest.
If you have a combination of large data in the database + heavily random routing criteria, the whole caching thing becomes a moot point anyway.
ehcache is the first thing that comes into my mind.
Good Luck.
_________________
LIFE is a series of complex calculations, somewhere multiplied by ZERO. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Apr 15, 2010 2:45 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
It is doable to implement routing logic with XML property -file (easy to maintain, and agile to change and can be revisioned together with other flow resources, parsing with xmlnsc domain etc.) stored at the q.
Flow should cache routing information at the SHARED ROW variable and refresh it from the xml stored in the q when needed (after mqsistart or mqsireload, with some refresh event etc.)
It is also doable to implement a simple web GUI for the routing information management with http -nodes.
--
Marko |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 15, 2010 5:28 am Post subject: Re: Routing Table - Using Database vs MQ Browse |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ayanc wrote: |
| Option 1 is a secure, tried and tested approach. I am keen to know about option 2. I have a feeling that option 2 could have better performance than option 1. |
A database solution will outperform a queue browse, which is a hideously inefficient WMQ operation. As you correctly point out it's easier to maintain & easier to control when you have multiple flows requiring slightly different data. With most modern database systems, a row like this which is frequently read will end up in the database cache memory so it'll be nearly as fast as reading it from inside flow memory.
Also from a best practice design standpoint, queues hold business data not system data. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
