| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Reasons to copy shared-row cache into environment? |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Thu Jun 08, 2017 7:22 pm Post subject: Re: Reasons to copy shared-row cache into environment? |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| simonalexander2005 wrote: |
| Code: |
-- This is the weird bit
DECLARE db REFERENCE TO CACHE;
CREATE LASTCHILD OF envRef.copiedCACHE FROM db;
END; |
|
The weird bit is the db REFERENCE variable. Why bother declaring a variable that only gets used once?
| simonalexander2005 wrote: |
| If the cache is ever updated in the Compute node (due to the contents of the message being such that it updates the cache), then the database, the SHARED ROW and the envRef.copiedCACHE are all updated at that point. |
Cache updates can occur immediately, but database updates are delayed until they are committed. And if some database updates are rolled back instead, then the cache could get out-of-sync with the database. It might be better for the Compute node to just mark the cache as unpopulated after committing any database transactions, and then let the next transaction repopulate it.
| simonalexander2005 wrote: |
| Why copy the SHARED ROW into the envRef.copiedCACHE at all? |
The SHARED ROW is a substitute for the querying the database, not for storing the results. Suppose the message flow didn't use a SHARED ROW; should each thread store the results from a database query somewhere, to use for the rest of the transaction, or should each thread repeatedly query the database instead, hoping that some random CPU scheduling provides some updates from any concurrent threads? If it's important that the updates from one transaction are seen by another, then that's a form of message affinity that is best not left to chance. The Environment tree is not shared, so it provides isolation, consistency, and can also improve performance, because the flow never needs to block other threads in order to access it. The Environment tree also has a broader scope, accessible throughout the entire flow, including subflows, regardless of schema or module, whereas shared variables are private to the flow, and to the schema or module where they're declared.
| simonalexander2005 wrote: |
| So, is the access to a SHARED ROW variable not threadsafe then? ... I can't see anything on thread safety of shared row variables in the documentation anywhere. |
No, that wouldn't be in the documentation. Thread safety is a property of the code, not the data. The question should be whether the developer wrote the code to handle SHARED variables in a thread-safe manner.
| simonalexander2005 wrote: |
| found it! - "... The broker always safely writes a new value to, and safely reads the latest value from, a shared variable. ..." |
No, that is about atomicity, not thread safety. A single read or write operation is atomic. Multiple read or write operations are not atomic, certainly not for "tens of thousands of entries".
| simonalexander2005 wrote: |
| although clearing and reloading it wouldn't be so good... hmm... - but if the clear happens in an ATOMIC block, the other threads would have to wait anyway, right? |
Right, but it's not enough to put just the clear and reload in an ATOMIC block. Any other read/write access to the SHARED cache would need to be inside ATOMIC blocks, too.
| simonalexander2005 wrote: |
| What from the article makes you say it's not threadsafe [at the statement level]? |
Maybe this: "The broker does not automatically provide higher-level locking than this (for example, locking covering the whole SET statement), because such locking is liable to cause "deadly embraces". "
| simonalexander2005 wrote: |
| The "SET count = count + 1" example is doing both a read and a write; so of course it's not threadsafe (count could be altered between the read and the write). It would require an ATOMIC block. |
What about statements like "SET square = Count * Count;" (with two reads but no writes)? Or statements like "SET startDate = CACHE.Root.{ID};" (with who knows how many reads, or if a parser gets involved, how many writes)? |
|
| Back to top |
|
 |
|
|
|
|
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
|
|
|
|
