ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Multiphase Commit » Is WebSphere MQ 7.0 compatible with SQL Server 2008

Post new topic  Reply to topic Goto page Previous  1, 2
 Is WebSphere MQ 7.0 compatible with SQL Server 2008 « View previous topic :: View next topic » 
Author Message
mdfaraz
PostPosted: Fri Sep 03, 2010 12:31 pm    Post subject: Equivalent in .NET? Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Fri Sep 03, 2010 1:36 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
bruce2359
PostPosted: Fri Sep 03, 2010 2:13 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
fjb_saper
PostPosted: Fri Sep 03, 2010 6:36 pm    Post subject: Re: Equivalent in .NET? Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Sandman
PostPosted: Mon Feb 13, 2012 8:12 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Feb 13, 2012 8:28 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Sandman
PostPosted: Mon Feb 13, 2012 9:07 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Mon Feb 13, 2012 9:10 am    Post subject: Reply with quote

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
View user's profile Send private message
Sandman
PostPosted: Mon Feb 13, 2012 9:12 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Mon Feb 13, 2012 9:28 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Sandman
PostPosted: Mon Feb 13, 2012 9:29 am    Post subject: Reply with quote

Centurion

Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI

Seeing I posted this question in two places and it's being answered in both, I'm going to focus back on my original thread:http://www.mqseries.net/phpBB2/viewtopic.php?p=324069#324069
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Multiphase Commit » Is WebSphere MQ 7.0 compatible with SQL Server 2008
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.