| Author |
Message
|
| shalabh1976 |
 Posted: Mon Jun 09, 2003 5:46 pm Post subject: Global Variable Storage |
 |
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Since MQSI does not support global variables, it has been suggested that either to use 1. Database or 2. Plugin node to save state data.
I have found that the usage of DB in the production environent has significant performance issues.
Does having a plugin node offer significant advantages ?
Has anybody got the pseudocode for it or is it available as a support pack ?
My production code is on OS390 but the development environment is NT. |
|
| Back to top |
|
 |
| Yanghui |
| Posted: Tue Jun 10, 2003 12:36 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
My understanding is that Enviornment tree normally is used for global variables through the whole message life time in msgflow. You can store data there in one node and use it in the other nodes.
Hope it helps.
-Yanghui |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 10, 2003 5:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, the Environment should be used for variables that need to maintain state during processing of a single message.
As shalabh1976 said, though, you can't save state across more than one message, unless you use a database or a custom node that's designed to hold state.
I can't speak about performance advantages of plug-ins over databases. I've never run any testing. It seems reasonable to expect that a very small plug-in will be faster than a database call, since there's no network communications involved.
As for pseudo code or examples, there are example plug-ins that come with WMQI. They normally get installed in <WMQIinstallDir>/Examples. |
|
| Back to top |
|
|
| Yanghui |
| Posted: Tue Jun 10, 2003 5:24 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
That's right that nothing available right away in WMQI if you want to save state across morn than one message. I met this problem before. I got around by using another queue to store the state as a message and MQGET node to get the message back during the next message processing. It has no performance compromise. The down side of this solution is that error-handling can be tricky and comprehensive.
It is an alternative.
-Yanghui |
|
| Back to top |
|
|
| leongor |
| Posted: Tue Jun 10, 2003 9:31 am Post subject: |
|
|
Master
Joined: 13 May 2002
Posts: 264
Location: Israel
|
Take a look at IA79 support pack. I´m not sure about supporting z/OS environment.
_________________
Regards.
Leonid.
IBM Certified MQSeries Specialist. |
|
| Back to top |
|
|
| shalabh1976 |
| Posted: Tue Jun 10, 2003 12:42 pm Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Thanks for all your replies.
I am making comprehensive use of the Envionment.Variables but state data cannot be stored thru it, so I am forced to use DB2.
I also looked at IA79 and it doesn't appear to be helpful for the mainframe environment.
So i'll stick to DB2 till IBM comes out with storing state data as a built in.
I think that this is a major requirement as state data is a critical requirement for middleware products.
What do you think ? |
|
| Back to top |
|
|
| mpuetz |
| Posted: Tue Jun 17, 2003 8:10 am Post subject: |
|
|
Centurion
Joined: 05 Jul 2001
Posts: 149
Location: IBM/Central WebSphere Services
|
Hi,
the problem with state data is that most of the time it must also
be persistet, so it can survive a broker crash. If your messages
are persistent in 99% of the case your state has to be persistent
as well. In that case storing your state in DB2 is as fast and
as good a choice as any, since you are going to have IO, no matter what.
Anyway a better design prinicple is to carry your state around in the message itself. The RFH2 header' <usr> section makes a good place for that. Of course your end apps/adapters have to support this.
If your state doesn't have to be persistent, I found that Mike Brady's Postit Plugin served me very well (if MsgId and/or CorrelId are suitable
primary keys for you state info).
_________________
Mathias Puetz
IBM/Central WebSphere Services
WebSphere Business Integration Specialist |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 17, 2003 8:22 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Quote: |
| Anyway a better design prinicple is to carry your state around in the message itself. |
Yes, this is a better design principle.
However, there are a number of design situations where it's not possible to use this principle, even if the applications could be modified to support it. A simple example is routing a group of messages based on the contents of the first message in the group. An even worse example is routing a group of messages based on the contents of the LAST message.
In the first example, you need to persist the routing decision. In the second, you need to persist the messages themselves. But in either case, it's not possible to use the messages themselves to store the necessary information.
More generally, any time you're working with a group of messages you probably need persistant storage across message flow invocations. |
|
| Back to top |
|
|
| kirani |
| Posted: Tue Jun 17, 2003 8:21 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| shalabh1976 wrote: |
Thanks for all your replies.
So i'll stick to DB2 till IBM comes out with storing state data as a built in.
I think that this is a major requirement as state data is a critical requirement for middleware products.
What do you think ? |
Another option would be to use a combination of MQOutput and MQGet Plug-in node to store persistant data.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
|
|
