Re: Backout/Commit on queue-level
Probably not, can't be certain with java as I just dont know. However given
the underlying call is likely to be MQCONN or MQCONNX then you get one
connection per queue manager per thread, any additional connections just
get given the same handle. So yes maybe you could do it by coordinating
mutli-threaded code although even that is not certain and the added
complexity in the code would make it hard to justify.
What problem are you trying to solve?
Regards
Tim A
"Christopher D.
Fryett" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED]cc:
T> Subject: Re: Backout/Commit on
queue-level
Sent by: MQSeries
List
<[EMAIL PROTECTED]
N.AC.AT>
17/03/2003 21:10
Please respond to
MQSeries List
Rainer,
Could you elaborate a little here. I would tend to think you would want
to use the backout/commit at a message level. So, when you commit a
message
it is recognized in the target queue as visible and committed. You would
use the backout if an error of some sort you designated occurred, and do
not
want it to be available in the target queue.
Chris
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rainer
Nonk
Sent: Monday, March 17, 2003 3:05 AM
To: [EMAIL PROTECTED]
Subject: Backout/Commit on queue-level
Hi all,
if i want to use MQs backout/commit feature on queue level: Can i
achieve this by creating an own MQQueueManager instance for each queue:
...
qMgr1 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
...
queue1 = qMgr1.accessQueue(...);
queue2 = qMgr2.accessQueue(...);
queue3 = qMgr3.accessQueue(...);
...
best regards,
rainer
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Backout/Commit on queue-level
No.
> -Original Message-
> From: Rainer Nonk [SMTP:[EMAIL PROTECTED]
> Sent: Monday, March 17, 2003 1:05 AM
> To: [EMAIL PROTECTED]
> Subject: Backout/Commit on queue-level
>
> Hi all,
>
> if i want to use MQs backout/commit feature on queue level: Can i
> achieve this by creating an own MQQueueManager instance for each queue:
>
> ...
> qMgr1 = new MQQueueManager("qm", env);
> qMgr2 = new MQQueueManager("qm", env);
> qMgr2 = new MQQueueManager("qm", env);
> ...
> queue1 = qMgr1.accessQueue(...);
> queue2 = qMgr2.accessQueue(...);
> queue3 = qMgr3.accessQueue(...);
> ...
>
> best regards,
> rainer
>
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Backout/Commit on queue-level
Rainer,
Could you elaborate a little here. I would tend to think you would want
to use the backout/commit at a message level. So, when you commit a message
it is recognized in the target queue as visible and committed. You would
use the backout if an error of some sort you designated occurred, and do not
want it to be available in the target queue.
Chris
-Original Message-
From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Rainer
Nonk
Sent: Monday, March 17, 2003 3:05 AM
To: [EMAIL PROTECTED]
Subject: Backout/Commit on queue-level
Hi all,
if i want to use MQs backout/commit feature on queue level: Can i
achieve this by creating an own MQQueueManager instance for each queue:
...
qMgr1 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
...
queue1 = qMgr1.accessQueue(...);
queue2 = qMgr2.accessQueue(...);
queue3 = qMgr3.accessQueue(...);
...
best regards,
rainer
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Backout/Commit on queue-level
Hi all,
if i want to use MQs backout/commit feature on queue level: Can i
achieve this by creating an own MQQueueManager instance for each queue:
...
qMgr1 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
qMgr2 = new MQQueueManager("qm", env);
...
queue1 = qMgr1.accessQueue(...);
queue2 = qMgr2.accessQueue(...);
queue3 = qMgr3.accessQueue(...);
...
best regards,
rainer
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: backout/commit on queue level
Where do you think the "whilst" came from? From: Tim Armstrong <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: backout/commit on queue level Date: Fri, 7 Mar 2003 10:54:09 +1100 Hursley is where the IBM development labs for MQ are located. Regards Tim A Rainer Nonk <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: backout/commit on queue level <[EMAIL PROTECTED] N.AC.AT> 07/03/2003 06:21 Please respond to MQSeries List Thomas Dunlap wrote: > Rainer, > > ...Maybe you can present you design to some IBM people (anyone in > Hursley listening) to see if they may be receptive. > I have heard this concern from a few of my clients through the last > few years. I just cannot say how wide spread the > concern really is in the community. Thank you very much for your answer! I am relatively new to MQ. So right now i don't know exactely what you've meant with your Hursley note. So could you please give me a hint ... ? best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: backout/commit on queue level
Hursley is where the IBM development labs for MQ are located. Regards Tim A Rainer Nonk <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: MQSeriescc: List Subject: Re: backout/commit on queue level <[EMAIL PROTECTED] N.AC.AT> 07/03/2003 06:21 Please respond to MQSeries List Thomas Dunlap wrote: > Rainer, > > ...Maybe you can present you design to some IBM people (anyone in > Hursley listening) to see if they may be receptive. > I have heard this concern from a few of my clients through the last > few years. I just cannot say how wide spread the > concern really is in the community. Thank you very much for your answer! I am relatively new to MQ. So right now i don't know exactely what you've meant with your Hursley note. So could you please give me a hint ... ? best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: backout/commit on queue level
Thomas Dunlap wrote: > Rainer, > > ...Maybe you can present you design to some IBM people (anyone in > Hursley listening) to see if they may be receptive. > I have heard this concern from a few of my clients through the last > few years. I just cannot say how wide spread the > concern really is in the community. Thank you very much for your answer! I am relatively new to MQ. So right now i don't know exactely what you've meant with your Hursley note. So could you please give me a hint ... ? best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: backout/commit on queue level
Rainer, The basis for control of units of work in WebSphere MQ is the HCONN from the MQCONN or MQCONNX calls. When the MQBACK or MQCMIT calls are performed, all messages under syncpoint control are acted upon for that particular application. If different applications place messages into the same queue under syncpoint, and one causes back out to occurs, messages for the other application are not affected. Now, for the multithreaded architecture, if your design is to have a predetermined number of WebSPhere MQ clients running having performed the MQCONN (to reduce overhead) this may be the real concern. I have seen these architectures used where the web server application is dynamically assigned a particular MQ client in a "round robin" fashion. This means that the same web application may not always be associated with the same MQ client application across subsequent requests. Since the web application really does not own the HCONN, the MQ client does, the MQBACK or MQCMIT applies to the MQ client application. This means that the UOW may contain messages for several different web applications. While it may be nice to have back out ot commit at a message level, the overhead would probably tend to become prohibitive. Back out or commit at a queue level would have the same concern described above, many different applications could put messages into the same queue. I believe what you are looking for is the ability to have UOWs based upon some user defined control. On z/OS this seems to be "in the works" with the implementation of Resource Recovery Services or RRS, system logger, Work load manager or WLM and the concept of "enclaves". I am not sure that all of the pieces may be in place at this point, but I have used RRS to coordinate changes between DB2 and WebSphere MQ. I must admit it did not involve a multithreaded environment. One curious thing in WebSphere for z/OS V5.3 is the addition of a ConnTag to the implementation of the MQCONNX call via the MQCNO structure. It sounds like it could be used as some style of control mechanism, but to this point I must admit I do not understand its function. I am in the process of doing more research. Maybe you can present you design to some IBM people (anyone in Hursley listening) to see if they may be receptive. I have heard this concern from a few of my clients through the last few years. I just cannot say how wide spread the concern really is in the community. The only real suggestion I can offer is to always have the application always associated with the same thread or to use the combination of MsgID and CorrelId plus a special recovery application to control the presence of messages in a queue before they are passed along to a back end application. The latter option requires a very specific application design based upon your environment and implementation by all applications involve in the same manner. I hope the helps out a little. I am sure that others will offer their own experiences and solutions. Rainer Nonk wrote: Hi Roger, thank you for your answer. So, what you do is mark with SYNCPOINT, via the get / put options, each message that you want to participate in a UOW. Any messages for other queues that you do NOT want to participate in the UOW then you mark then with NO_SYNCPOINT. Best would be a commit/backout feature for each message. Second best a commit/backout feature for each queue. But that seems to be not possible. The *drawback* of your solution is: I can have only ONE "commit/backout Queue", any MANY "ordinary Quenes". Because i intended to use a multithreaded architecture, with parallel put/get operations, and at least three similar such "commit/backout Queues", it seems this is not possible at all. Or does somebody have another suggestion ? Best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive -- Regards, Thomas DunlapChief Technology Officer[EMAIL PROTECTED] Themis, Inc.http://www.themisinc.com1 (800) 756-3000
Re: backout/commit on queue level
Hi Roger, thank you for your answer. > So, what you do is mark with SYNCPOINT, via the get / put options, each message > that you want to participate in a UOW. Any messages for other queues that you > do NOT want to participate in the UOW then you mark then with NO_SYNCPOINT. Best would be a commit/backout feature for each message. Second best a commit/backout feature for each queue. But that seems to be not possible. The *drawback* of your solution is: I can have only ONE "commit/backout Queue", any MANY "ordinary Quenes". Because i intended to use a multithreaded architecture, with parallel put/get operations, and at least three similar such "commit/backout Queues", it seems this is not possible at all. Or does somebody have another suggestion ? Best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: backout/commit on queue level
Hi, The answer is a "qualified yes". What I mean by that is an application can ONLY have 1 outstanding Unit of Work (UOW). It does NOT matter if the UOW is local or global. So, what you do is mark with SYNCPOINT, via the get / put options, each message that you want to participate in a UOW. Any messages for other queues that you do NOT want to participate in the UOW then you mark then with NO_SYNCPOINT. i.e. MQGetMessageOptions getOptions = new MQGetMessageOptions(); getOptions.options = MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_SYNCPOINT; or MQGetMessageOptions getOptions = new MQGetMessageOptions(); getOptions.options = MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_NO_SYNCPOINT; Note: Anything outside of a UOW (with NO_SYNCPOINT option) is committed immediately (i.e. NO commit or rollback). Hope that helps. later Roger... Quoting Rainer Nonk <[EMAIL PROTECTED]>: > Hello, > > I understood that it's possible to use commit/backout on Queue Manager > level. > But is it possible to use MQs syncpoint feature on Queue level ? > > For example, i have four queues on one Queue Manager, and want to commit each > SINGLE > message - and not EVERYTHING which is in my four Queues. > > Is this possible in MQ, especially with JAVA ? > > best regards, > Rainer > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
backout/commit on queue level
Hello, I understood that it's possible to use commit/backout on Queue Manager level. But is it possible to use MQs syncpoint feature on Queue level ? For example, i have four queues on one Queue Manager, and want to commit each SINGLE message - and not EVERYTHING which is in my four Queues. Is this possible in MQ, especially with JAVA ? best regards, Rainer Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
