tags:

views:

460

answers:

5

Hi,

I have an application that retrieves data and stores into a database once per day. Until recently this application has resided on the same machine as the SQL server but due to some hardware issues with some of the required peripherals, it has been moved to a seperate machine running windows XP.

The problem we are having here, is that when the first transaction of the morning is run, we receive a stack trace of the following:

System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.

However, immediately rerunning the transaction again is successful. It seems as though the MSDTC is taking too long to respond to the first transaction and is thus, failing but is then ready for the second. I have found several references to this occurring on the internet but have found no real solution. Has anyone encountered this? If so, is there a way of preventing MSDTC from unloading from memory or is there another solution for this such as extending time outs?

A: 

I recommend you first look in the event logs of all machines involved and see what else is there. You're making an assumption about what's going on. It could be a good assumption, but I suggest you find out before making changes.

I'm also going to start the process of moving this question over to ServerFault, where you'll probably get a faster answer. If it takes too long (five people have to vote), then you may want to go ask the question over there manually. If you do, then indicate that the original (and past the link) is probably on its way.

John Saunders
A: 

One thing to look at (and it may not be the cause of your problem), is to make sure that the reverse DNS lookup on the client's IP actually resolves to a name that refers to the client machine. We had problems with our DNS/DHCP setup, where an IP was matched to multiple names. When the remote end of MSDTC tried to connect back to the MSDTC on the client, it was attempting to connect to a different machine.

This will manifest as (seemingly random) transaction timeouts.

geofftnz
A: 

Oh dear we have also been facing the same problem. We were migrating data from one database to another (with different structure) and was using Subsonic to speedup the process. We used transactions and SharedDbConnectionScope object and it failed simillarly on the machine running XP SP3. I think there are some updates in SP3 that breaks the things as it is working fine on Vista, 2003 and 2008 Servers.

EDIT: Here is an MSDN KB article that discusses the same problem.

TheVillageIdiot
A: 

You could probably try running a process which simply initiates and commits a transaction on the DTC every 30 minutes or so?

Spence
+1  A: 

Thanks guys,

Just to fill you in, we have resolved the issue by changing the dcom config to use the remote coordinator located on the SQL server, so far we have not experienced any further issues.

Wulfkind