| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ATOMIC block and SHARED variables confusion |
« View previous topic :: View next topic » |
| Author |
Message
|
| jharringa |
 Posted: Tue Jun 30, 2009 6:56 am Post subject: ATOMIC block and SHARED variables confusion |
 |
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
In InfoCenter the documentation says:
| Quote: |
| It is not necessary to use the BEGIN ATOMIC construct in flows that will never be deployed with more than one instance (but it might be unwise to leave this to chance). It is also unnecessary to use the BEGIN ATOMIC construct on reads and writes to shared variables. The broker always safely writes a new value to, and safely reads the latest value from, a shared variable. ATOMIC is only required when the application is sensitive to seeing intermediate results. |
It further explains that the only reason you'd need to do that if you are incrementing a counter because both flows may get the same value and then increment.
I would like to use this for a routing scenario. To me, this would indicate that if I wanted to implement a memory cache with shared variables I would not need to wrap the usage of the cache with an atomic block as it seems that it would be implicit. So I decided to take a look at the handy Message Routing samples. The samples seem to paint a completely different picture in their comments:
| Quote: |
To speed the processing, the first action will only be done when the first message enters the message flow. The retrieved database table will be stored in memory for any other messages to use. The cache can also be refreshed by putting a message onto the CACHE.MEMORY.REFRESH queue.
It is important to note that all this processing is surrounded by a begin atomic block. This makes sure that only one message accesses the cache at a time. This is very important because the cache could be refreshed at any point. If two messages are using the cache at the same time then one could refresh the cache while the other one is using it. If refreshing is not going to be used or only used when the message flow has been stopped then the BEGIN ATOMIC statement END; can be moved to just before the start of part 2. This is to make sure that the initialization of the cache is single threaded. The ATOMIC block is given a label called "ROUTING". It is important to label ATOMIC blocks because all ATOMIC blocks with in a message flow, with the same label, share the same lock even if they are in different compute nodes. |
Is the sample possibly out of date or am I just missing something and maybe there is something that I gain when I'm using a shared row.
I thought about sending a PMR to IBM but I figured I'd try and get my story straight first. I could be missing something. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 30, 2009 7:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I believe what you are seeing here is the difference between a shared variable and a shared row.
That is, the value of a shared variable is always guaranteed to be updated atomically, but the value of a SHARED ROW is the pointer to the first child. So the pointer will be updated safely, but that has nothing to do with the contents of the ROW itself. |
|
| 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
|
|
|
|
