error message
The server process has lost its connection with MS-DTC. This is expected if MS-DTC has stopped, or if MS-DTC failover has occurred on a cluster.
Server Application ID: {02D4B3F1-FD88-11D1-960D-00805FC79235}
Server Application Instance ID:
{D9197A81-84FB-4051-8AA9-F1156151D6C0}
Server Application Name: System Application
The serious nature of this error has caused the process to terminate.
Error Code = 0x8004d01c : A connection with the transaction manager was lost.
------------------------------------
출처 : http://weblogs.asp.net/rhurlbut/archive/2004/01/02/47211.aspx
..more
>접기
I have been spending most of this week (yes, even on New Year's Day as well!) working out some issues I have been having with Enterprise Services (ES), as I mentioned some of my work in a previous post. This is also a continuation of Sam's thoughts that he posted about our work on the ES architecture for our client.
In particular, we are running distributed transactions against Oracle, using Oracle's Data Provider for .Net (typically has better performance than Microsoft's version). I have been able to get everything to work correctly using Windows 2000 and Windows XP. When using Windows Server 2003, we are having issues.
According to this article: http://support.microsoft.com/?id=817066, some things have changed with MS DTC in regards to security (in the right direction, I might add). You need to enable XA transactions, as well explicitly add an XADLL registry entry that contains your resource manager's XA transaction manager dll. No problem. After much research, it appears that this is Oracle's file (for 9.2.0.x version): heteroxa9.dll. The problem is when that file reference is put in place, it doesn't seem to work. We are still puzzling through this as I write this, but I want to at least blog about it to see if anyone else had similar problems (or, hopefully, solutions).
A hack that works, but doesn't give me the real solution is to set all but one of the connection strings to the various resource managers to “Enlist=false“. What this means is you can single out one of the connections to use COM+, and the others won't (in other words, these connections can still see the TransactionId, but rollbacks won't be possible on this connection because they weren't “enlisted“ in the distributed transaction). Again, that's a hack, and doesn't give you real distributed transactions -- it just simply takes MS DTC out of the picture. So, as far as I can tell the issue is with Window Server 2003 and the new MS DTC changes, not with Enterprise Services.
I have spent time as well really digging underneath the covers of ES to determine how it all works and interacts with COM+. One point I made a couple of days ago in a previous post was it appeared as long as the namespace System.EnterpriseServices was referenced by an assembly, then that assembly's methods could be involved in a transaction, even though the assembly class itself may not be derived from ServicedComponent (a requirement in order to be a “configured” component). Upon further checking, I noticed that these three key assemblies also reference System.EnterpriseServices by default: System.Data.dll, System.Web.dll, and System.Web.Services.dll.
As an example, within System.Data, as you might expect, if a COM+ Transaction is detected, then if a local transaction has started, it is rolled back, and the System.Data.SqlClient.Transaction class takes over to allow a COM+/ES transaction to take place instead. Interesting stuff.