| Author |
Message
|
| prasadzkv |
 Posted: Fri Aug 05, 2016 1:27 am Post subject: How to release shared row cache info. |
 |
|
Novice
Joined: 13 Jul 2016
Posts: 21
Location: Chennai
|
Team,
I am using shared row i can able to archive the data flow level (one compute node to another compute node) but i want to release the cache information.
Example:
If am using 3 compute nodes in the 2nd(second) compute node i tried to release the cache info from shared row using the following commands.
A)SET mySharedRow = NULL;
B)DELETE FIELD mySharedRow;
C)SET mySharedRow.Rows = NULL;
D)DELETE FIELD mySharedRow.Rows;
But still i can able to get the cache info inside of 3rd compute node.
If am wrong please correct me.
input->compute1->output->compute2->output->compute3->output.
please help me!!! |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Fri Aug 05, 2016 1:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Why go to the trouble of using a shared variable for this?
Do you want the data in it to persist between messages? From your problem description I guess you don't.
Why not put it into the LocalEnvironment?
Then copy the InputLocalEnviroment to the OutputLocalEnvironment until you get to the last Compute node where you don't need it. Then either just not copy it if you don't need anything else in the LE or just set the LE root field for the data to NULL.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Aug 05, 2016 4:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
Why go to the trouble of using a shared variable for this?
Do you want the data in it to persist between messages? From your problem description I guess you don't. |
| smdavies99 wrote: |
| Why not put it into the LocalEnvironment? |
Or just put it in the Environment and don't bother passing it.
How did you come up with a SHARED variable as the solution to your requirement? Did it result from the same extensive research that led you to the conclusion that hard coding a JDBC configurable service was an optimum solution? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 05, 2016 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| Did it result from the same extensive research that led you to the conclusion that hard coding a JDBC configurable service was an optimum solution? |
For full details and some more quality sarcasm, see here.
The coffee machine is broken. Happy Friday. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 05, 2016 4:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| The coffee machine is broken. Happy Friday. |
*fake cough* *fake cough* "Sorry, boss, I seem to be getting sick. Gotta go home... "
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Aug 05, 2016 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| The coffee machine is broken. Happy Friday. |
*fake cough* *fake cough* "Sorry, boss, I seem to be getting sick. Gotta go home... "
|
Give it 30 more minutes. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| prasadzkv |
| Posted: Mon Aug 08, 2016 9:26 pm Post subject: |
|
|
Novice
Joined: 13 Jul 2016
Posts: 21
Location: Chennai
|
Thanks smdavies99 for suggest on the same. But i would like to know how to release shared row cache info. for the shake of example purpose only provides the node concept.
 |
|
| Back to top |
|
|
| adubya |
| Posted: Mon Aug 08, 2016 10:53 pm Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
The previous comments were inquiring as to why a SHARED variable was being used to share data between flow compute nodes. It's a good question as there are better ways of doing this. You need to understand what a SHARED variable does and the implications of using one, you might find some "interesting" side effects if you add more instances of the flow using it.
If you really, really must use one and understand the implications then we'd have to see your code (embedded in [code] tags) to see how you were declaring, setting, accessing and "releasing" the variable.
_________________
Independent Middleware Consultant
andy@knownentity.com |
|
| Back to top |
|
|
| mayheminMQ |
| Posted: Tue Aug 09, 2016 3:17 am Post subject: |
|
|
Voyager
Joined: 04 Sep 2012
Posts: 77
Location: UK beyond the meadows of RocknRoll
|
@prasadzkv
Treat Any shared variables as normal variables but stays in memory until your flow is redeployed or restarted. If you are using Shared row, the way to clear the contents is to set the field to NULL. Ensure they are done at the right place in your message flow.
This advice is only for you to play around with Shared variables and not for using it in the message flow that you had earlier.
_________________
A Colorblind man may appear disadvantaged but he always sees more than just colors... |
|
| Back to top |
|
|
| prasadzkv |
| Posted: Tue Aug 09, 2016 8:14 pm Post subject: |
|
|
Novice
Joined: 13 Jul 2016
Posts: 21
Location: Chennai
|
Thanks mayheminMQ and adubya,
COMPUTE 1:
----------
DECLARE mySharedRow SHARED ROW;
DECLARE initialized SHARED BOOLEAN myINIT();
CREATE COMPUTE MODULE ShredRow_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot.XMLNSC.Top.TEST.Result1 VALUE = initialized;
SET OutputRoot.XMLNSC.Top.TEST.Result2 = mySharedRow;
END;
END MODULE;
CREATE FUNCTION myINIT( ) RETURNS BOOLEAN
BEGIN
LOG EVENT VALUES('myINIT CALLED');
SET mySharedRow.Top[] = SELECT A.emp_id, A.emp_name from Database.Test.employee AS A;
RETURN TRUE;
END;
COMPUTE 2:
----------
CREATE COMPUTE MODULE ShredRow_Compute1
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF (mySharedRow IS NOT NULL) THEN
SET OutputRoot.XMLNSC.Test1.TestRes.Result2 = mySharedRow;
SET mySharedRow = NULL;
END IF;
RETURN TRUE;
END;
COMPUTE 3:
----------
CREATE COMPUTE MODULE ShredRow_Compute2
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
IF mySharedRow IS NOT NULL THEN
SET OutputRoot.XMLNSC.TestFinal = mySharedRow;
END IF;
RETURN TRUE;
END;
In first compute node am initializing the shared row and 2nd compute node verifying 'IF (mySharedRow IS NOT NULL) THEN ',
But this condition it self failing as well as tried like with out if condition and set mySharedRow is null even though in 3rd compute node it self failing the if condition.
Please correct me! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Aug 09, 2016 10:27 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I don't use constructs like
| Code: |
IF mySharedRow IS NOT NULL THEN
|
I much prefer something like this
| Code: |
if coalesce(myScharedRow.Top[1].emp_id,0) <> 0
|
the capitalisation of 'emp_id' might be wrong but that depends upon your DB table.
However I really do think you need to follow the advice of adubya when he says this
| Quote: |
You need to understand what a SHARED variable does and the implications of using one, you might find some "interesting" side effects if you add more instances of the flow using it.
|
If you do get your flow working and want to speed things up by adding another instance you will be in deep do-do. Your flow will just not work as you want it to.
From what you have described so far there really is no justification for even considering using shared variables as a solution.
My suggestion for using the LocalEnvironment (or Environment) is IMHO the right way to go.
If you learn how to use Usertrace and understand the output you may get more insight into why your current code is failing. The 'Debugger' is not the only way to skin the IIB debugging cat.
_________________
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 |
|
|
| Craig B |
| Posted: Tue Sep 20, 2016 4:35 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
I have tried your scenario in 10.0.0.6 and it works fine for me.
There is no XMLNSC message created in the last compute node as the SHARED ROW is blank.
What Version+fixpack level of the product are you using?
In your sample ESQL you would have to be careful putting "SET OutputRoot = InputRoot" in each compute node. If you did that then you final Compute node would just flow the XMLNSC tree you created in the second compute node which would give you the impression the Shared Row variable was still there.
_________________
Regards
Craig |
|
| Back to top |
|
|
|
|
