| Author |
Message
|
| ceteareth |
 Posted: Mon Nov 17, 2014 3:11 am Post subject: Shared Row Issue |
 |
|
Acolyte
Joined: 12 Aug 2012
Posts: 51
|
first off....hi everyone 
I recently encountered an issue regarding the caching approach discussed in this article.
http://www.ibm.com/developerworks/websphere/library/techarticles/1405_dunn/1405_dunn.html
I have 2 messages flows.
First messageflow has a timeout notification node which sends a dummy message to message flow#2 line flow 1.
Message flow #2 has two line flow(2 input queue which has different path).
The first line flow receives the dummy request then pulls records from DB then creates a child in the shared row for each database record.
| Code: |
CALL getCache(test, Environment.ResultSetConfig[]) IN Database.{schemaName};
SET sharedCache = NULL;
FOR cacheline AS Environment.ResultSetConfig[] DO
CREATE LASTCHILD OF sharedCache NAME cacheline.key VALUE cacheline.value;
END FOR;
|
Message flow #2 line flow 2 is the flow being triggered when we want to retrieve a particular value from the cache(shared row).
| Code: |
DECLARE value CHARACTER COALESCE(sharedCache.{key}, '');
|
The code works as expected. The value from cache is retrieved accordingly. The issue arise once the instance is increase. In our case when additional instance is set to 10 we are unable to retrieve the value from cache. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Nov 17, 2014 10:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Could be a concurrency problem. Could be that you are trying to retrieve a value from the cache before it is populated...
Are you embedding your cache operations with BEGIN ATOMIC? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| maurito |
| Posted: Tue Nov 18, 2014 12:54 am Post subject: |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
The article is clear:
| Quote: |
| For readability, loading of the cache is shown without an ATOMIC block, which works only when one thread is running the message flow. There are other ways to search the cache, such as using FOR or WHILE loops, but using SELECT is the fastest. |
|
|
| Back to top |
|
|
| ceteareth |
| Posted: Tue Nov 18, 2014 8:15 pm Post subject: |
|
|
Acolyte
Joined: 12 Aug 2012
Posts: 51
|
i read through the article again and found the statement posted by maurito.
I updated the code to make use of ATOMIC.
do i need to wrap the read operation with atomic or do i need to wrap both.
at the moment the read and write are on the same message flow but have different flow line(different input queue).
write is done only once which is when the flow is loaded(a timeout node sends a message to the writer flow).
the application works perfectly when instance is one but once i changed the instance via the webui thats when the issue arise. |
|
| Back to top |
|
|
| ceteareth |
| Posted: Tue Nov 18, 2014 8:21 pm Post subject: |
|
|
Acolyte
Joined: 12 Aug 2012
Posts: 51
|
| @fjb_saper - i am sure that the cache has been populated already since ive already run a couple of test with additional instance set to 0. I changed the instance thru the webui and i also did not test the app right away. i give it a minute before sending out a message |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Nov 18, 2014 10:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| ceteareth wrote: |
| @fjb_saper - i am sure that the cache has been populated already since ive already run a couple of test with additional instance set to 0. I changed the instance thru the webui and i also did not test the app right away. i give it a minute before sending out a message |
I did not check the code for the cache population. Make sure it does not get populated on the first message through the flow...
This is why you might want both read and write to be atomic.
If the cache is in memory and there, that operation should be so fast that it is unlikely to become your bottleneck. However the first pass loading is a bottleneck, hence the need for atomic.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| maurito |
| Posted: Wed Nov 19, 2014 1:12 am Post subject: Re: Shared Row Issue |
|
|
Partisan
Joined: 17 Apr 2014
Posts: 358
|
so, the issue is not with the caching article, whatever caching mechanism you use you will have a problem.
you need:
1- an indicator to flag whether the cache has been populated.
2- the read operation does NOT need to be single threaded (atomic), but you need to check that the cache has been loaded, and if it has not, then load it (atomic ) and update the flag accordingly.
3- test. |
|
| Back to top |
|
|
|
|
