| Author |
Message
|
| ariel135 |
 Posted: Sun Apr 20, 2008 11:27 am Post subject: need help in comitting several sessions together thanks! |
 |
|
Newbie
Joined: 20 Apr 2008
Posts: 9
|
well, i'm working on a program, and in my program i have an array of sessions, each item connects to a diffrent queue manager via client connection and opens a specific queue.
i created few functions "put, get, commit and backout"
when i put a message, i dont know where the message would really be, it can be in a random session.
when i call my "Commit", i need it to commit the entire array, but if any of the queue manager inside fails committing, i need an entire backout. (in this way, one will commit and the other one fails, then the user receive "fail" RC, and will try to send the msgs again, which will cause double messages in the queue managers...)
this i understand i can do with "Extended Transactional Client" and the XA, well, i purchaed and installed the ETC, but i have no further idea how to continue.
do i need to add any refrenece? how can i start approaching it?
my program is written in MQI which i wrapped to the C++/CLI so i can use it later in .net, i use Websphere MQ 5.3 CSD 13
any direction how to start?
thanks
ariel. |
|
| Back to top |
|
 |
| Nigelg |
| Posted: Sun Apr 20, 2008 12:04 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
It is not possible.
Only one WMQ unit of work can be part of a transaction; the UoW is linked to the connection. Multiple connections cannot be linked together into a single transaction.
The ETC is only of use where the TM is an external coordinator, and the WMQ connections are RMs in the transaction. I suppose it may be possible to have multiple WMQ RMs in a single transaction; you will have to find suitable software to be the TM, and consult its documentation.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Apr 20, 2008 12:35 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
Additionally, queue manager can be either a transaction manager or a resource manager, but not both.
As noted earlier in this post, a WMQ unit of work cannot span queue managers.
So, it seems you are looking for a transaction manager, like BEA Tuxedo, TXSeries, or some similar XA-Compliant transaction manager.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Apr 20, 2008 6:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Update to V 6.0.2.3 and get the JCA adapter. With that plus the ETC you should be able to use any J2EE compliant appserver as TM.
To be safe check with your IBM Rep and don't take my word for it.
BTW 5.3 is out of support! (unless you are on NTSC?) 
Enjoy 
However if you want my advice I'd re-engineer this. Client connections across the network bring their own share of troubles into a coordinated transaction...
Put your message to multiple remote queues on the same local qmgr that point to the various local queues on the remote qmgrs. Simple, one qmgr, one session, one transaction...
You can then have point to point connections between the qmgrs. Or if you need to simplify admin you could have an MQ Cluster... 
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ariel135 |
| Posted: Mon Apr 21, 2008 2:21 am Post subject: thanks for the quick reply, but... |
|
|
Newbie
Joined: 20 Apr 2008
Posts: 9
|
| I can't use single qmgr cuz I'm writing an api, I need to distrib it to unknown number of people who will use it. My goal is to create a smart client which then the user will just send and my API will do the rest - send it to any of the qmgrs. When I'm not using transactions it works perfectly but the transactions is a problem. I hate to install 3rd party program cuz then I'll have to install it to every server.. But if its the only way.. What's the recommended one? I can't upgrade to 6 cuz its not fully tested in my org yet. Any more ideas? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 21, 2008 2:36 am Post subject: Re: thanks for the quick reply, but... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ariel135 wrote: |
| I can't use single qmgr cuz I'm writing an api, I need to distrib it to unknown number of people who will use it. My goal is to create a smart client which then the user will just send and my API will do the rest - send it to any of the qmgrs. |
Slightly off topic here, but what is the problem you're trying to fix here? You've got an app, which client connects to a queue mamanger, where the queue manager could be one of any number of queue managers anywhere and can't be determined ahead of time. Got that.
Faced with this situation, I'd code the app to connect to a queue manager called "SOMEQM", and let the local WMQ admin put as many "SOMEQM" entries in a channel table as he wanted or needed to. This would also allow transactions, using the ETC.
Why are you building multiple connections in the app?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ariel135 |
| Posted: Mon Apr 21, 2008 8:44 am Post subject: Ok i'll explain again: |
|
|
Newbie
Joined: 20 Apr 2008
Posts: 9
|
i'm writing an API, in this API, the user can choose to send to a specific destination, it can be either queue, distribution list, multiple session list.
which then the user only opens a Destination and sends the message:
Dest.Put(Msg);
he doesnt care what is the real destination, its in my xml file which i configure to him.
One of the objects is a MultipleDestination, which encapsulate a list of queue managers (which i'm configurating to him),
Lets say i'm opening 2 queues:
TEST
and TEST2
and i have 3 queue managers:
QMGR1
QMGR2
QMGR3
then, i have:
2 multiple destinations
| |
\ /
each multiple destination, holds 3 queues:
TEST on QMGR1, TEST on QMGR2 TEST on QMGR3
the other multiple destination holds:
TEST2 on QMGR1, TEST2 on QMGR2 and TEST2 on QMGR3
each of the queues, holds THE QMGR HANDLE "hconn"
(because it will kill to open for each queue a new session, if i already connected to the 3).
Lets think of a "client round robin", each message will go to another queue manger.
QUEUE_TEST.Put(msg) ===== will go to QMGR1
then QUEUE_TEST.Put(msg) ===== will go to QMGR2
then QUEUE_TEST.Put(msg) ===== will go to QMGR3
now, i'm using my second multiple destination:
QUEUE_TEST2.Put(msg) ===== will go on to QMGR1
so far, QUEUE_TEST is on QMGR1
and QUEUE_TEST2 is on QMGR2
The user then calls MultipleSession Commit.
MultSess.Commit();
inside, i have to loop all the sessions and do a commit job.
if the second one fails, the first one DID the commit successfully, and the user gets an error actually, cuz the second one didnt succeed.
the user sends the msgs again, because the commit fails, but no... the first commit succeeded, this will cause the same msgs to be put again...
i have to sync the entire commits...
is it clear now  ?
any idea? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 21, 2008 1:24 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What value are you adding on top of JNDI?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ariel135 |
| Posted: Mon Apr 21, 2008 9:32 pm Post subject: JNDI? |
|
|
Newbie
Joined: 20 Apr 2008
Posts: 9
|
Java Naming and Directory Interface?
i'm not using any java, i can't use it.
its in c# eventually, i wrapped the MQI in c++/cli |
|
| Back to top |
|
|
| bower5932 |
| Posted: Tue Apr 22, 2008 5:19 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I haven't read through this append in detail, but it sounds like you want to be able to commit several messages in a single unit of work. Why don't you client connect to a single queue manager and put the messages onto remote queues to the other queue managers? You can then commit the single unit of work against the single queue manager. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Apr 22, 2008 5:46 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
If you have only 2 qmgrs then you can roll your own single phase commit.
e.g.
to move messages between 2 qmgrs
1) get FROM
2) put TO
3) commit TO
4) if 2 + 3 successful, then commit FROM, else PANIC
Providing there is not a problem commiting (1) then it is watertight.
WAS does a similar trick with its last participant support that allows a single non-XA resource to participate in a global transaction. |
|
| Back to top |
|
|
| markt |
| Posted: Tue Apr 22, 2008 7:00 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 504
|
| Quote: |
| 4) if 2 + 3 successful, then commit FROM, else PANIC |
er ... 3.5) system crashes. What's the state now?
Last-participant optimisation requires that other participants be able to handle two-phase operations.
So you also need to add step 1.5) PREPARE. And how do you do that? You need a TM. (In fact you can do interesting things with the regular MQI to emulate a TM, even without using MQBEGIN, but it's not a simple as you suggest.)
Last edited by markt on Tue Apr 22, 2008 7:06 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 22, 2008 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| markt wrote: |
| Quote: |
| 4) if 2 + 3 successful, then commit FROM, else PANIC |
er ... 3.5) system crashes. What's the state now?
|
I suspect that's why you PANIC 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| markt |
| Posted: Tue Apr 22, 2008 7:08 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 504
|
| No. Because if the system crashes you don't even reach step 4. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Apr 22, 2008 2:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Sounds to me more and more like PUB/SUB with persistent messages...
Assured QoS should then do the rest.
Oh Yeah I noticed the little cluster twist. 
Just subscribe with delivery to queue://clusteralias/destqueue
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
