| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Is WebSphere MQ 7.0 compatible with SQL Server 2008 |
« View previous topic :: View next topic » |
| Author |
Message
|
| mdfaraz |
 Posted: Fri Sep 03, 2010 12:31 pm Post subject: Equivalent in .NET? |
 |
|
Novice
Joined: 31 Mar 2010
Posts: 19
Location: Houston, TX
|
| Quote: |
| Here the qmgr will act as transaction manager and as such needs to know about the XA resource, hence this statement. |
That means the queue manager exposes API to somehow 'know' the XA resource.
Why don't I see this method in my .NET QueueManager class (amqmdnet.dll)
I dont get why 2 way commit in .NET/SQL server DB is so different from Java/DB2.
Can anyone validate if SQL Server is NOT XA-compliant? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Sep 03, 2010 1:36 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| That means the queue manager exposes API to somehow 'know' the XA resource. |
XA code location and supported services are specified in a qmgr .ini file (or equivalent Win Registry). This XA registration allows the application to make use of XA facilities and services.
| Quote: |
| Why don't I see this method in my .NET QueueManager class (amqmdnet.dll) I dont get why 2 way commit in .NET/SQL server DB is so different from Java/DB2. |
Because the XA stuff is done by the qmgr, at the qmgr, at execution-time. and in base MQI code; and NOT in provider class code.
Keep in mind that the qmgr really only understands and executes the base MQI (Message Queue Interface) calls. The WMQ APR lists the languages that WMQ supports MQI calls directly - C, COBOL, PL/1, Visual Basic, z/OS (s/390) Assembler. For Java, JMS, .NET, and other provider classes, these calls are wrapped/encapsulated in source code; and must be unwrapped to MQI calls.
| Quote: |
| Can anyone validate if SQL Server is NOT XA-compliant? |
Do a quick Google search for SQL+XA. The first hit answered the question for me.
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Sep 03, 2010 2:13 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Briefly, very briefly, this is how an XA transaction is managed. I encourage you to do research on Google for more details.
When an application changes a resource (like a DB call or an MQPUT in syncpoint), a Logical Unit of Work ID (LUWID) is created; and all subsequent resource changes by this app are associated with this LUWID. More importantly, these changes are logged by each resource manager (MQ, DB2, others) involved in the transaction, and the log records include the LUWID.
When the app decides to commit the changes, the transaction coordinator/manager directs each resource manager to commit changes associated with the specific LUWID for this app. Each resource manager will communicate to the transaction manager that it has committed its changes. If any of the resource managers cannot (for whatever reason) commit, then the transaction manager will direct the resource managers to roll back (backout) the changes.
_________________
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: Fri Sep 03, 2010 6:36 pm Post subject: Re: Equivalent in .NET? |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mdfaraz wrote: |
| Quote: |
| Here the qmgr will act as transaction manager and as such needs to know about the XA resource, hence this statement. |
That means the queue manager exposes API to somehow 'know' the XA resource.
Why don't I see this method in my .NET QueueManager class (amqmdnet.dll)
I dont get why 2 way commit in .NET/SQL server DB is so different from Java/DB2.
Can anyone validate if SQL Server is NOT XA-compliant? |
That's because the .NET model does not work the same way.
You will need to use the MSTC Transaction manager and enroll both MSSQL and WMQ as resources in the transaction.
Read up on the using .NET manual. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 8:12 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
This isn't specific to SQL Server, but a general question about how a resource manager (DB2) works with a transaction coordinator (MQ).
If app does MQPUT and DB2 insert, then breakpoint at MQCMT. While at breakpoint, I taskkill all MQ processes (to simulate queue manager dying). Then I step over MQCMT. As expected, app catches exception and logs, but doesn't attempt backout (seeing it knows qmgr is gone).
How and when (if ever) does DB2 realize that it can cleanup the uncommitted thread? We're seeing that it just hangs onto it and we have to kill it.
Am I missing something? Thank you. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 13, 2012 8:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes. You are describing a Unit of Work, or Unit of Recovery. WMQ can participate in UofW's in several ways. And, yes, DB2 can also be a participant in a UofW.
And, yes, there are administrative things you must do to enable this.
This is nicely documented in the InfoCenter.
_________________
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 |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 9:07 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
I understand the UOW and we actually have the two-phased commit (and backout) configured and working properly.
I'm asking if/when/how DB2 cleans up orphaned threads that were launched as part of a 2PC UOW but whose transaction coordinator has gone away. When the queue manager comes back, would it communicate to DB2 to tell it to release the lock? (It doesn't seem to.) Or must we configure DB2 to timeout locked threads after some interval? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 13, 2012 9:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The queue manager is only involved to the extent that it is either participating in or managing the 2pc.
If the DB thread is not being released, then it's likely that the application itself hasn't released the thread. So see what happens when you actually quit the application - either forcefully or gracefully. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 9:12 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Tried that. Stopping app still didn't release DB2 thread.
I just found this in another thread:
| Quote: |
| If you restart your qmgr, all transactions that are not committed or prepared (ie. have completed 1st phase of the 2 phase commit) are rolled back. |
http://www.mqseries.net/phpBB2/viewtopic.php?t=52065
So seeing my app was stopped at the MQCMT before I killed MQ, DB2 hadn't yet "asked" DB2 to prepare to commit. So would this uncommitted DB2 transaction also be rolled back on qmgr restart? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 13, 2012 9:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes.
_________________
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 |
|
|
| Sandman |
| Posted: Mon Feb 13, 2012 9:29 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
