| Author |
Message
|
| phaniIIB |
 Posted: Tue Mar 29, 2016 11:28 am Post subject: IBM MQ - Syncronous/Asynchronous behavior |
 |
|
Acolyte
Joined: 28 Jul 2015
Posts: 51
|
Hi all,
I have a question if IBM MQ is capable of handling multiple requests concurrently at the same time.
For example, if 2 or more applications want to write/read data to a single queue at the same time, can it handle. If so can some one explain how it handles lock/release mechanism.
Thanks in advance. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Mar 29, 2016 11:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
IIB can handle synchronous or asynchronous behavior.
The behavior depends on the transport.
How IIB handles it depends on the transport.
If you want to work with MQ in IIB, you should study MQ first.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 29, 2016 11:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| If you want to work with MQ in IIB, you should study MQ first. |
That's nothing to do with IIB and everything to do with MQ. IIB is just another MQ aware application in the circumstance you describe.
You could ask the same question in a Java forum and get the same answer for the same reason.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 29, 2016 11:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
That's one of the many benefits of MQ, it can handle multiple putters or getters at the same time (on the same queue), without corrupting anything or delivering the same message more than once. The application just calls the API (MQI).
Obviously inside the queue manager code, there are serialisation mechanisms to ensure integrity of the memory buffers and/or file storage that holds the messages (and logs). I don't know what it uses exactly - but it clearly works and works very well and very fast.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Mar 29, 2016 11:31 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Having dabbled with writing my own queue manager in the 1980's I can tell you that getting the locking working was the hardest part of the operation.
I ran into all soerts of problems until I went back to the drawing board and made the I/O to the QMGR use an OS function.
Thankfully, the operating system I was using had a very elegant (IMHO) design and could handle Async stuff very easily.
I ended up using a lot of the OS features to get the QMGR working properly.
Using QIO and QIOW functions of the OS made it all work very nicely.
This was on a PDP-11 running RSX-11M/S.
Ahhh. Those were the days of getting into writing kernel level code and debugging everything using a single VT100 terminal.
_________________
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 |
|
|
|
|
