locked
"Communication with the underlying transaction manager has failed." RRS feed

  • Question

  • Hello,

    seems that TransactionScope has some serious problems  - only if more than one connection is enlisted in TransactionScope. With one connection everything works fine.

    We use in our application TransactionScope and last year- in december 2006, after I've changed my computer (anothrer IP, another station name), saving in TransactionScope did not work anymore. Just on my station - on my colleagues stations worked fine. I've tried to solve it, we discussed about this problem on forum, but no chance...

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=955571&SiteID=1

    http://ronua.ro/CS/forums/permalink/11423/11423/ShowThread.aspx#11423

     

    After winter holiday when IT department made some changes(clean stuff) in network IPs,  my problem dissapeared - I could save in TransactionScope as if nothing would happened before.

     

    But.....yesterday, some changes have made in IP network...and surprise  :  my TransactionScope started to freak me out again...   and: for 3 stations in the same office, one works fine, and mine and  the other one do not work . Why, in case that only one connection is enlisted works fine, and for the second everything cracks?

     

    Here is the message
    System.Transactions.TransactionManagerCommunicationException was caught
      Message="Communication with the underlying transaction manager has failed."
      Source="System.Transactions"
      StackTrace:
           at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
           at System.Transactions.TransactionStatePSPEOperation.PSPEPromote(InternalTransaction tx)
           at System.Transactions.TransactionStateDelegatedBase.EnterState(InternalTransaction tx)
           at System.Transactions.EnlistableStates.Promote(InternalTransaction tx)
           at System.Transactions.Transaction.Promote()
           at System.Transactions.TransactionInterop.ConvertToOletxTransaction(Transaction transaction)
           at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
           at System.Data.SqlClient.SqlInternalConnection.EnlistNonNull(Transaction tx)
           at System.Data.SqlClient.SqlInternalConnection.Enlist(Transaction tx)
           at System.Data.SqlClient.SqlInternalConnectionTds.Activate(Transaction transaction)
           at System.Data.ProviderBase.DbConnectionInternal.ActivateConnection(Transaction transaction)
           at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
           at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
           at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
           at System.Data.SqlClient.SqlConnection.Open()
           at CommonBONUtils.Utils.InsertLogTransaction(Int32 BOID)

     

    Thanks a lot
    Tuesday, August 21, 2007 12:31 PM

Answers

  •  

    Hello, to anyone who read this post Big Smile..maybe it is helpful

    Although when I had the same problem in december I tried to fix it with Dcping and didn't worked, seems that today, when I've changed GUID for MSDTC in HKEY_CLASSES_ROOT\CID registries and the problem is solved for my station. Tomorrow I will check on my collgeague station that doesn't work.

    Thanks

    Ela

    Thursday, August 23, 2007 11:24 AM

All replies

  •  

    Hello, to anyone who read this post Big Smile..maybe it is helpful

    Although when I had the same problem in december I tried to fix it with Dcping and didn't worked, seems that today, when I've changed GUID for MSDTC in HKEY_CLASSES_ROOT\CID registries and the problem is solved for my station. Tomorrow I will check on my collgeague station that doesn't work.

    Thanks

    Ela

    Thursday, August 23, 2007 11:24 AM
  • Be careful in changing the GUIDs under HKCR\CID. These GUIDs are used to identify the RPC endpoints. If there is some child DTC that has an in-doubt transaction due to a failure after it voted "prepared", that child DTC has stored the RPC endpoint of the parent DTC in order to try to reestablish communications. If the parent DTC changes its GUID, the child will not be able to re-connect to the parent to find out the outcome because the parent will never listen on the old RPC endpoint.

     

    With that said, it sounds like maybe you had CID entries that were the same as the server you were trying to communicate with. Two DTCs that have the same CID GUIDs will refuse to talk to each other. Theoretically this shouldn't happen, but in situations where machines are getting setup using various tools that don't know that the CID entries need to be different will just copy them over. Then, if the two DTC try to talk to each other, it will fail.

     

    SysPrep involves DTC when setting up a machine from a copy and that involvement includes generating unique GUIDs for the CIDs.

     

     

    Friday, August 24, 2007 5:09 PM
    Moderator
  •  

    What changes did you make to the GUID?

     

    Monday, August 27, 2007 9:09 PM
  • So finnaly have you solved out the problem? If yes, could you please outline the exact way?
    Friday, November 2, 2007 4:13 AM
  •  

    Everybody, if anyone is still reading this.

     

    We had the same problem described in this thread: we were using TransactionScope to create a distributed transaction within a WCF service invocation among two DB servers. After trying everything any article described in the internet, we couldn't find the solution. In our scenario we were using Vista Business machines connecting to a Windows 2003 Server; some computers connected without problems, but others failed even though everything was configured exactly the same way. Some computers that used to work fine one day would simple stop working.

     

    However, we had a lucky strike: we found out that if you change your IP, the problem seems to get corrected. In our particular case, we tested changing from a Dynamically generated IP via DHCP to an static IP that was different from the one the DHCP was assigning to the machine. Suddenly it worked.

     

    We speculate that something somewhere is managing a list of connections/transactions/something between the machine and the server and for some reason stops accepting connections from the IP. We don't know what or yet.

     

    If anybody finds out the real reason underneath this problem, please let us know.

     

    Hope this workaround helps.

     

    Regards,

     

    Andragon

    Monday, March 10, 2008 8:01 PM
  • Hey People,


    Thanks a lot, this post saved my soul.


    I was having the same problem. and in my case i was with a static IP.
    I just changed my IP for dynamic and it started to work.


    Thanks again,

    Adolpho Galindo
    Tuesday, September 22, 2009 6:14 PM
  • I know this thread is dead now but I encountered a similar problem and wanted to post a solution. Here was the stack trace we got (it looks very similar to the one above):

    Exception type: TransactionManagerCommunicationException Exception message: Communication with the underlying transaction manager has failed.. Stack trace: at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
    at System.Transactions.TransactionStatePSPEOperation.PSPEPromote(InternalTransaction tx)
    at System.Transactions.TransactionStateDelegatedBase.EnterState(InternalTransaction tx)
    at System.Transactions.EnlistableStates.Promote(InternalTransaction tx)
    at System.Transactions.Transaction.Promote()
    at System.Transactions.TransactionInterop.ConvertToOletxTransaction(Transaction transaction)
    at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
    at System.Data.SqlClient.SqlInternalConnection.GetTransactionCookie(Transaction transaction, Byte[] whereAbouts)
    at System.Data.SqlClient.SqlInternalConnection.EnlistNonNull(Transaction tx)
    at System.Data.SqlClient.SqlInternalConnection.Enlist(Transaction tx)
    at System.Data.SqlClient.SqlInternalConnectionTds.Activate(Transaction transaction)
    at System.Data.ProviderBase.DbConnectionInternal.ActivateConnection(Transaction transaction)
    at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
    at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
    at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
    at System.Data.SqlClient.SqlConnection.Open()
    at Microsoft.CommerceServer.Internal.Marketing.ConnectionContainer..ctor(String marketingConnectionString, String listConnectionString)
    at Microsoft.CommerceServer.Internal.Marketing.PromoCodePipelineHelper.RedeemHelper(IDictionary order, IDictionary context)
    at Microsoft.CommerceServer.Internal.Marketing.RedeemPromoCodesPipelineComponent.Execute(Object orderFromPipeline, Object contextFromPipeline, Int32 flags)

    The problem was that we were trying to use DTC between one server in a workgroup and another in a domain. To resolve it we used the following article: http://support.microsoft.com/default.aspx/kb/555017. Be sure to set the hosts entry for the machine name on both the client and server.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, February 4, 2010 4:29 AM
  • I just resolved this issue on a client.  The client had a static IP but was missing the WINS server entries.  When I switched to DHCP things worked.   So I noted the differences using ipconfig /all and then set the manual IP configuration to be the same except for the static IP address.
    Thursday, September 6, 2012 9:07 PM