|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Who uses XA with WMQI/MQSI? |
« View previous topic :: View next topic » |
Who uses XA for there WMQI MWSI setup? |
Yes I use XA, you have to |
|
40% |
[ 2 ] |
No I don't use XA, but I don't to DB updates |
|
0% |
[ 0 ] |
No I don't use XA, I do DB updates, but i like living on the edge |
|
20% |
[ 1 ] |
Huh, WTF is XA |
|
40% |
[ 2 ] |
|
Total Votes : 5 |
|
Author |
Message
|
warrenpage |
Posted: Tue Jul 16, 2002 10:58 am Post subject: Who uses XA with WMQI/MQSI? |
|
|
Acolyte
Joined: 19 Feb 2002 Posts: 56 Location: Australia
|
Just wondering how many people setup WMQI systems with XA transaction processing (via MQ)?
If you don't and you have Database updates - why not? Do you just take the risk? Do you use any other methods to mitigate the risk?
If you offload DB updates to a queue and get another pgm to do the updates, how do you make sure that your DB updates happen in a timely fashion so that the event the message triggers has access to data in the DB (in cases where the event needs the DB data you generate/store from a flow).
I know the following
a) If you are not doing DB updates, then you don't need XA
b) I could just get the flows working queue to queue and then offload DB updates to another process, that works under local DB transactionality.
My concern is that under option b) is that if the DB update queue/pgm goes down, that the events triggered by the flow message will not see the DB updates (as they are still waiting on a queue), and have no way of knowing if the DB is in error, or just waiting for an update.
I have been told that XA limits performance. How badly should I avoid it? Or should I just suck it up and use it.
My gut feeling is that a production system needs XA, and if I do DB updates then I need it. Am I wrong, am i missing something?
Warren |
|
Back to top |
|
 |
Tibor |
Posted: Tue Jul 16, 2002 1:06 pm Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
You are theoretically right, and I am planning to switch on this functionality, too ... but look this article from IBM website "Independent Performance report on MQSeries Integrator Version 2" (http://www-3.ibm.com/software/ts/mqseries/library/scalablesolution.PDF)
It contents the next observation:
"Use of Transactional and XA Options. CSC recommends using MQSI transactional integrity only if needed as it does increase processing time. With the appropriate tuning, the overhead of using transactional integrity is manageable, as demonstrated by attaining the target GSTP workload of 330 messages per second. Using transactional integrity requires the use of persistent queues.
Using XA adds significantly to the overhead of the MQSI transaction processing and its use should be limited to situations where there are no other design alternatives and where performance is acceptable. Not only does the use of XA significantly reduce throughput, it also greatly complicates system administration and management."
... er.... so I hesitate... |
|
Back to top |
|
 |
warrenpage |
Posted: Wed Jul 17, 2002 3:56 pm Post subject: thats what I was afraid of.. |
|
|
Acolyte
Joined: 19 Feb 2002 Posts: 56 Location: Australia
|
I guess I could just take the risk..
as i'll probably not be with the company by the time the first crash happens and they resend a million dollar payment transaction..
Need to make sure I have someone to blame before that happens..  |
|
Back to top |
|
 |
kirani |
Posted: Wed Jul 17, 2002 4:28 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
In my current project, we are doing batch Interfaces using WMQI. I have configured MQSeries to act as Transaction coordinator and DB2 UDB as RM to participate in 2-phase commit. My Client wanted to use MSSQL Server as Application Database, but, since it is not supported by MQSeries for 2-phase commit, we moved to DB2 UDB. I cannot use external application to do DB updates. It is hard to avoid DB updates in my message flows, because I am storing global variables into database, which will be shared across messages.
If you are doing DB updates, I would strongly recommend using 2-phase commit. You will have BIG trouble if your transaction rollback or Broker crashes.
In my previous project we implemented real time interfaces, where we were doing transformation of financial transactions and all db transactions were globally coordinated. So far ... I didn't hear from those guys, so I am assuming everything is going fine for them!  _________________ Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
Back to top |
|
 |
warrenpage |
Posted: Wed Jul 17, 2002 6:06 pm Post subject: Nice to know |
|
|
Acolyte
Joined: 19 Feb 2002 Posts: 56 Location: Australia
|
Thanks for that note Kiran.. Nice to know it works fine..
Yeah I think we pretty much have to do it to. Our transaction rate targets aren't too aggressive, so we should be ok.
What sort of transaction rates were you getting on those other systems? |
|
Back to top |
|
 |
Tibor |
Posted: Wed Jul 17, 2002 9:43 pm Post subject: |
|
|
 Grand Master
Joined: 20 May 2001 Posts: 1033 Location: Hungary
|
kirani wrote: |
In my previous project we implemented real time interfaces, where we were doing transformation of financial transactions and all db transactions were globally coordinated. So far ... I didn't hear from those guys, so I am assuming everything is going fine for them!  |
Kiran,
I didn't say any bad about XA and I don't wanna talk anyone out of using it... but we have a relatively weak WMQI server, that's why I am anxious.
Tibor |
|
Back to top |
|
 |
kirani |
Posted: Thu Jul 18, 2002 4:58 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001 Posts: 3779 Location: Torrance, CA, USA
|
I am sure my client have relatively strong configuration in Production now. Last time when I talked to folks over there, they were having 3 Sun (server) MQSI 2.0.1 servers with 8 CPUs each, and one fail over server. This system was designed to operate 24x7 mode.
The processing speed on QA box was around 30-40 msgs per second. Things have changed a lot since then. With every release of CSD, performance increases and things get better!! _________________ Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
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
|
|
|
|