EntLib 3.0, SqlDatabase.ExecuteXmlReader & System.Transactions

Topics: Data Access Application Block
Feb 28, 2007 at 4:10 AM
Will the SqlDatabase.ExecuteXmlReader be receiving the same System.Transactions support as Database.ExecuteReader etc have been given? It currently appears to have the 'auto-close' behavior...

Thanks,
Andrew
Feb 28, 2007 at 1:25 PM
What do you mean by auto-close behavior?

It supports System.Transactions based on the source code:

public XmlReader ExecuteXmlReader(DbCommand command)
{
   SqlCommand sqlCommand = CheckIfSqlCommand(command);
 
   ConnectionWrapper wrapper = GetOpenConnection(false);
   PrepareCommand(command, wrapper.Connection);
   return DoExecuteXmlReader(sqlCommand);
}

The GetOpenConnection(false) method call checks to see if a transaction is occurring and, if so, uses the same connection. The passing of false as an argument says not to close the inner-connection, because you will need to close it yourself.

Regards,

Dave

_______________________

David Hayden
Microsoft MVP C#
Mar 1, 2007 at 11:22 AM
Hi Dave: Thanks for taking the time to reply. I've looked at the EntLib source now too - and think I understand better what it's doing and, yes, I understand the connection management responsibilities this method places on the caller. The problem I have (which I'm still tracking) appears to be the state the underlying connection is left in when you have an encompassing System.Transactions.TransactionScope and an exception is thrown across the scope boundary... Possibly not an EntLib issue... but if I track it down I'll re-post on this thread.

Cheers.
Mar 3, 2007 at 5:47 AM
For other folk using ExecuteXmlReader and System.Transactions: Don't close your command.Connection if you're within a TransactionScope.

For example, where previously you might have had:

if (cmd.Connection != null)
    cmd.Connection.Close();

Then now you will want:
if ((cmd.Connection != null) && (Transaction.Current == null))
    cmd.Connection.Close();

Cheers.