msdtc not available

jhw posted on Thursday, September 13, 2007

I am using the <Transactional(TransactionalTypes.TransactionScope)> for a parent object. As I understand it, this will allow system to automatically see if distributed transactions are required(which I don't have).

My parent object saves ok, but when I try to update the child editable collection, I get an error saying the msdtc is not available. I assume that it is looking for a distributed transaction server. I don't see why.

I call my child collection update after the end of the using block in the parent, as per the Project example in the book. Is this example dependant on having dtc. Is there a different way I have to create my child updates, perhaps passing in a transaction or connection.

Heath

Cslah replied on Thursday, November 01, 2007

I'm running into this also every now and then when I forget. I guess it makes sense that we can pass this through when LocalContext is valid, like when we're not using the remote dataportal.

I've got objects that are sometimes used on their own and sometimes they're called within the DataPortal of another object. Seems to be my command objects are this way? So, for simplicity, wouldn't it make sense to set the connection to use the LocalContext all the time, like at application startup (assuming that it's not going to change). Then in the DataPortal methods, check to see if it's null. If it's null (remote dataportal) then grab it like normal, otherwise use it from the LocalContext.

It would seem to be cleaner and more consistent this way? Opinions?

RockfordLhotka replied on Thursday, November 01, 2007

There’s a Microsoft guy who blogged about a connection manager a few months ago. Unfortunately I don’t remember who it was.

But he created an IDisposable object to contain a connection. Each new “user” of the object (each using block) just incremented a counter within the class. Each time a using block exits it calls Dispose(), and that decremented the counter. When the counter hit zero the real connection was disposed.

His implementation of this stored the connection itself in TLS. However, you could easily do the same thing but store the connection in LocalContext (which would be safer, because that works in both normal and ASP.NET environments).

I actually posted something along this line in an earlier thread

http://forums.lhotka.net/forums/thread/15902.aspx

(found via www.lhotka.net/search.aspx - google is your friend!!)

Rocky

From: Cslah [mailto:cslanet@lhotka.net]
Sent: Thursday, November 01, 2007 5:10 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] msdtc not available

I'm running into this also every now and then when I forget. I guess it makes sense that we can pass this through when LocalContext is valid, like when we're not using the remote dataportal.

For simplicity, wouldn't it make sense to set the connection to use the LocalContext all the time, like at application startup (assuming that it's not going to change). Then in the DataPortal methods, check to see if it's null. If it's null (remote dataportal) then grab it like normal, otherwise use it from the LocalContext.

It would seem to be cleaner and more consistent this way? Opinions?

Cslah replied on Monday, November 26, 2007

Revisiting this again...

I can't use the ConnectionManager in post 15902 because I'm using datareaders in my child objects and it seems that a single connection can only have a single open datareader (I'm using Csla 3.0 and I'm not using ASP.Net either).

There isn't any particular reason why I'm using nested datareaders, other than it seems to be what the eBooks encourage. Should I not be using them? I would think that parent-child relationships are very common and that people use datareaders within the child objects, so I'm a bit perplexed why this isn't a very common topic on the groups. This leads me to believe that I'm doing something out of the norm (which isn't intentional).

So, I guess passing the connection down to the child object using LocalContext is the way to go? Not sure why it works when passing it using LocalContext but doesn't using the ConnectionManager. Maybe it gets closed and re-opened? Any ideas?

Thanks,
Brian

RockfordLhotka replied on Monday, November 26, 2007

ADO.NET 2.0 introduced this concept called MARS – multiple asynchronous result sets. My understanding is that MARS does allow you to open multiple datareaders on a single connection. I haven’t explored it, but you may want to look into this idea.