| Author |
Message
|
| SapanaK |
 Posted: Thu Jan 10, 2013 8:46 am Post subject: Constants in esql |
 |
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
Hi All,
We have lot of esql constants declared in our project and mainly due to limitation that constants declared in same broker schema can be accessed from given esql, we have had to put all of this in same schema.
These common declarations have helped us deem lot of benefits like standardisation of code, single place change,reuse already declared and defined stuff to name a few.
However, we recently observed that this is impacting our bar size adversely - on a closer look we found that -
1. All the constants whether being referred in given flow, or subflows/procedures it use, are added in every module of the flow. To quote numbers, for 162 unique constants decalred, the total number of occurances in compiled message flow was close to 7000+
To get around this problem, by referring to some of the posts in this forum we tried to adopt the getter function approach - it seemed like a perfect solution as it allowed us to reorganize appropriately in different schemas. However the next roadblock was that due to esql problem that every call to a function need to have a SET in its LHS –
So we can have
SET a = SUCCESS_CODE( ),
but not as
CALL BuildResponse(reqHdrRef,SUCCESS_CODE(),Environment);
Most of these constants used in the fashion as -
DECLARE SUCCESS_CODE CONSTANT CHARACTER 'S';
CALL BuildResponse(reqHdrRef,SUCCESS_CODE,Environment);
Is there a way by which we can tackle the bar size problem(which also impacts memory consumption) and also retain benefits of constant declarations? We donot mind changing existing code, as long as it is not too complicated a change
Thanks,
Sapana
Last edited by SapanaK on Fri Jan 11, 2013 5:27 am; edited 1 time in total |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Jan 10, 2013 9:33 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Your view of code reuse is skewed. You may think that you are getting some benefit from piling all your constants and esql code into one location, but in reality, you are creating a maintenance challenge.
I would guess this style came from WMB V6. WMB V8 offers a better way to package common code.
Bar size is not really an issue. You should be segmenting and dividing your code rather than trying to pile every burger patty into one bun.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Jan 10, 2013 9:51 am Post subject: Re: Constants in esql |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| SapanaK wrote: |
Is there a way by which we can tackle the bar size problem(which also impacts memory consumption) and also retain benefits of constant declarations? We donot mind changing existing code, as long as it is not too complicated a change |
I guess both the approaches you have mentioned above has its own problems. Though you have reduced the BAR file size, the number of CALL's you make to the external Java class has increased.
How does the size of the BAR file (in the first approach) have an big impact here when compared to the JAR file (in the second approach) that you deploy to the EXG-GRP?
What is the version of WMB you are working on? |
|
| Back to top |
|
|
| mgk |
| Posted: Thu Jan 10, 2013 10:01 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Code: |
| CALL BuildResponse(reqHdrRef,SUCCESS_CODE(),Environment); |
This code should work - how did you define the getter function?
Kind regards
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Jan 10, 2013 2:45 pm Post subject: Re: Constants in esql |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| SapanaK wrote: |
| However the next roadblock was that due to esql problem ... |
What was the problem? |
|
| Back to top |
|
|
| SapanaK |
| Posted: Fri Jan 11, 2013 2:24 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
Thanks everyone for your reply.
@Lancelotlinc - I agree, that declaring all constants is not a good idea, however, since we use v7.0 of WMB we have no choice but to put everything in one schema - we ourselves have been wanting to reorganize it for long. I will check out if WMB v8.0 helps us here - but product upgrade is not something that is within our control.
@kash3338 - The overhead for function calls, I agree, but thats a tradeoff when the team is huge, and the dev cycles are really short. The code readability/compactness has been prime concern. On the size impact, since the constants become function calls, they are added to cmf only if they are being referred/used.
@mgk - Unfortunately, the code compiles, but doesn't deploy.
@rekarm01 - the problem was, as I mentioned above, we can't simply replace Constans being used in esql statements with function call. It seems you can only pass a character variable as a parameter to function call, not a funciton that would return character.
Any suggestions?
Last edited by SapanaK on Fri Jan 11, 2013 5:31 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jan 11, 2013 2:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I see your trouble and your confusion.
Per definition a constant is not mutable. As such you cannot use it in ESQL as you would use a variable... and would have to rely on a number of things...
a) in order to define the value only once (and as I understand you do that in Java) you would need to:
- create a static java function for each variable type
- create an ESQL schema with reference to your java project
- model each of the java functions in ESQL
- define the constant in the ESQL schema as constant type with the call to the java function like:
DECLARE CINT1 CONSTANT INTEGER CALL jconst_integer('cint1');
- in java, depending on the value of "cint1" you would then serve up the value of the corresponding constant. (Remember correct type translations).
- have the programmer use the constants with their schema prefix?
This way you can enforce the constant behavior of your esql constants...
If you cannot reference the variable from a different schema, you can retrieve the value using the ESQL function template, but if the programmer did not define the variable as constant, you have no way of enforcing the constant behavior in ESQL.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Jan 11, 2013 2:51 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| @mgk - Unfortunately, the code compiles, but doesn't deploy. |
With what error? Can you also post the fucntion definition?
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| SapanaK |
| Posted: Fri Jan 11, 2013 4:48 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
@fjp_saper - thanks for your inputs. The method we adopted was - no constant declarations at all - all of them way straight way replaced with getter functions -
What was declared as
DECLARE SUCCESS_CODE CONSTANT CHARACTER 'S';
was changed to -
CREATE FUNCTION SUCCESS_CODE ( ) RETURNS CHARACTER
BEGIN
RETURN 'S';
END;
@mgk - you had me at it! I got back to get that error, and it seems to be working perfectly. may be some unreferenced variable was being accessed, and in the heat we just put it down to this change. Thanks for pointing that this should definitely work.
Thanks all for your inputs.
When we do end up with a flow modified with this approah, we would do a test to see the performance hit, if any. I hope the overhead would be under control, I would update this post with the finding.
Last edited by SapanaK on Fri Jan 11, 2013 5:24 am; edited 1 time in total |
|
| Back to top |
|
|
| kash3338 |
| Posted: Fri Jan 11, 2013 5:01 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| SapanaK wrote: |
When we do end up with a flow modified with this approah, we would do a test to see the performance hit, if any. I hope the overhead would be under control, I would update this post with the finding. |
If my understanding is correct, your two approches are like below,
1. Define 'n' number of CONSTANT variables in your code under a schema and refer the same in the flows within the same schema.
2. Create a Java class which has 'n' number of Static getter methods, which will be invoked form the message flow.
I would like to know from the experts here on which is the better way to do this. Both have their own performance issues, but somehow I feel the Java invocation has a overhead, as there can be 'n' CALL's to the Java method for a single transaction.
Going with the Java approach would be really useful only if you are trying to access only few constant values and not ALL for a particular transaction. Is that the way it works in your flow? |
|
| Back to top |
|
|
| SapanaK |
| Posted: Fri Jan 11, 2013 5:15 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
@kash338 - that's right. The first approach mentioned below is how the code currently is. And we would edit few of the flows as per approach2.
We would then have 2 EG's, having exactly same bunch of services written in approach 1 and 2 deployed, and tested. Use exactly same test messages and run test pack of 100s of these for approach1 EG. and then repeat for EG2.
We mainly want to look at -
1. Test Pack response time.
2. Memory consuption of the 2 EG's
Anything else that we should be looking at? |
|
| Back to top |
|
|
| SapanaK |
| Posted: Fri Jan 11, 2013 5:36 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2012
Posts: 9
|
@kash338 - just to clarify, may be I misquoted causing confusion, we are using functions in esql only - I only meant to convey that they are styled similar to getter functions in java.
The performance overhead I am referring to is - the cost of calling these esql functions, compared to direct usage of esql constants. |
|
| Back to top |
|
|
|
|
