| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Need some clarification on ATOMIC BLOCK |
« View previous topic :: View next topic » |
| Author |
Message
|
| 547c547 |
 Posted: Wed Nov 26, 2014 10:03 pm Post subject: Need some clarification on ATOMIC BLOCK |
 |
|
Acolyte
Joined: 16 Jun 2014
Posts: 51
|
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Nov 26, 2014 10:56 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
If you propagate from inside an ATOMIC Block try to guess what will happen to other threads trying to access that same code?
OR to put it another way...
How long is a piece of string?
Answer, you don't know.
The same applies to the thread that you propagate with. How long could that thread run for? milliseconds, seconds, minutes? You just don't know.
If I ever had to review some code with a PROPAGATE from within an ATOMIC block I'd get the red pen out in a flash and reject it.
Sure you might get away with it but..... do you want to risk it? Do you want to risk blocking some important messages?
Your call entirely.
_________________
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 |
|
|
| 547c547 |
| Posted: Wed Nov 26, 2014 11:45 pm Post subject: |
|
|
Acolyte
Joined: 16 Jun 2014
Posts: 51
|
| smdavies99 wrote: |
If you propagate from inside an ATOMIC Block try to guess what will happen to other threads trying to access that same code?
OR to put it another way...
How long is a piece of string?
Answer, you don't know.
The same applies to the thread that you propagate with. How long could that thread run for? milliseconds, seconds, minutes? You just don't know.
If I ever had to review some code with a PROPAGATE from within an ATOMIC block I'd get the red pen out in a flash and reject it.
Sure you might get away with it but..... do you want to risk it? Do you want to risk blocking some important messages?
Your call entirely. |
COOL... I got it,.. Thank you for elucidation..  |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Thu Nov 27, 2014 6:24 am Post subject: Re: Need some clarification on ATOMIC BLOCK |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| 547c547 wrote: |
| I heard that we should not use PROPAGATE in atomic block.. Is that true? If so why? |
The broker doesn't allow PROPAGATE statements within an ATOMIC block; deploys fail with a BIP2526 error (Illegal ATOMIC block usage.) So, whether you should or shouldn't use one is academic.
The rationale for disallowing PROPAGATE statements is to avoid deadlocks. For example, if one ATOMIC block were nested within another, each with its own label (mutex), and two different threads with a lock on each mutex were waiting for the other thread to release its mutex, then the two threads would become deadlocked. PROPAGATE statements make it more difficult (or impossible) to detect whether ATOMIC blocks in different ESQL nodes are effectively nested, so it's simpler to just disallow PROPAGATE statements in ATOMIC blocks altogether.
However, there are arguably legitimate uses for propagating to non-ESQL nodes within an ATOMIC block; for example, to implement a simple file cache, where a message flow copies the file contents into a local shared variable, but wants to avoid reading the file more than once:
| Code: |
BEGIN ATOMIC
IF SharedVariable is empty THEN
Read file and copy into EnvironmentVariable
Copy EnvironmentVariable into SharedVariable
ELSE
Copy SharedVariable into EnvironmentVariable
END IF;
END; |
Using a FileRead node would require a PROPAGATE statement, so there's no way to implement this within a single ATOMIC block. It could be coded with two separate ATOMIC blocks, before and after the PROPAGATE statement, but then guaranteeing the message flow reads the file only once gets a lot more complicated. |
|
| Back to top |
|
|
| 547c547 |
| Posted: Thu Nov 27, 2014 9:40 pm Post subject: Re: Need some clarification on ATOMIC BLOCK |
|
|
Acolyte
Joined: 16 Jun 2014
Posts: 51
|
| rekarm01 wrote: |
| 547c547 wrote: |
| I heard that we should not use PROPAGATE in atomic block.. Is that true? If so why? |
The broker doesn't allow PROPAGATE statements within an ATOMIC block; deploys fail with a BIP2526 error (Illegal ATOMIC block usage.) So, whether you should or shouldn't use one is academic.
The rationale for disallowing PROPAGATE statements is to avoid deadlocks. For example, if one ATOMIC block were nested within another, each with its own label (mutex), and two different threads with a lock on each mutex were waiting for the other thread to release its mutex, then the two threads would become deadlocked. PROPAGATE statements make it more difficult (or impossible) to detect whether ATOMIC blocks in different ESQL nodes are effectively nested, so it's simpler to just disallow PROPAGATE statements in ATOMIC blocks altogether.
However, there are arguably legitimate uses for propagating to non-ESQL nodes within an ATOMIC block; for example, to implement a simple file cache, where a message flow copies the file contents into a local shared variable, but wants to avoid reading the file more than once:
| Code: |
BEGIN ATOMIC
IF SharedVariable is empty THEN
Read file and copy into EnvironmentVariable
Copy EnvironmentVariable into SharedVariable
ELSE
Copy SharedVariable into EnvironmentVariable
END IF;
END; |
Using a FileRead node would require a PROPAGATE statement, so there's no way to implement this within a single ATOMIC block. It could be coded with two separate ATOMIC blocks, before and after the PROPAGATE statement, but then guaranteeing the message flow reads the file only once gets a lot more complicated. |
Awesome.. Pretty cool. THANK YOU SO MUCH  |
|
| 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
|
|
|
|
