BUG? Enterprise Library 3.1 - Connection control

Topics: Data Access Application Block, General discussion
Jul 27, 2007 at 2:21 PM
The data application block 3.1 automaticaly closes the connection and control the connection pool.
The problem that I have when I try to use this version off enterprise library is:

http://forums.microsoft.com/msdn/showpost.aspx?postid=1602667&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=1

Sometimes the system returns error in SQLDataReader.GetOrdinal method and some users suggests don't use the connection pool to avoid the error. I would allow the data application block manager my connection. I can't force the connection close because I sometimes use transactionscope.

The most interesting think is the version EntLib 2.0 the error don't happen.

What should I do to avoid this error? I have this error in production envoriment and I need to solve quickly... Please help me? I want to use Enterprise Library 3.1 and I don't want to downgrade my system.

Jul 27, 2007 at 4:00 PM
Hi,

I'm not sure the DAAB controls the connection pool as described in the longeve post in the msdn forums, as they are referring to an ADO.NET feature controlled through the connection string.
They also describe scenarios where the DAAB is not being used and the issue shows up very rarely or under heavy load. Can you characterize your scenario? How often do you get this error? Does it happen consistently or randomly? Is transaction scope being used when the error shows up?

Regards,
Fernando
Jul 27, 2007 at 6:48 PM
Fernando,

Can you characterize your scenario?
==> I have 2 windows services in 2 machines in loading balacing - Windows Server 2003. The services are called using .NET Remoting and some operation are executed in the services.


How often do you get this error? Does it happen consistently or randomly?
==> the error ocurrs randomly. For example: I tested more than 10.000 times yesterday without error. Suddenly the error ocurrs.
==> It's started happen with I migrated to Enterprise Library 3.1 from 2.0.


Is transaction scope being used when the error shows up?
==> No. The error ocurrs more in transaction scope, but I get this error in method without transaction.



Thanks.
Francisco Daniel



fsimonazzi wrote:
Hi,

I'm not sure the DAAB controls the connection pool as described in the longeve post in the msdn forums, as they are referring to an ADO.NET feature controlled through the connection string.
They also describe scenarios where the DAAB is not being used and the issue shows up very rarely or under heavy load. Can you characterize your scenario? How often do you get this error? Does it happen consistently or randomly? Is transaction scope being used when the error shows up?

Regards,
Fernando

Aug 14, 2007 at 1:10 PM
Hi Francisco,

I'm sorry about not getting back to you on this before.

You will understand this is a tricky issue to diagnose, as it appears to occur randomly and it's not even known if the issue is exclustive to the DAAB based on the long thread on the ADO.NET forum you linked.

Can you set up an isolated repro for this issue to better diagnose it? It will likely need more detailed infrastructure information.

Regards,
Fernando
Dec 11, 2007 at 1:27 PM
Hi,

I got a similar problem, the connection pool seems to be full and this error occurs (no Message and no InnerException) just a stack trace :

at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
at System.Data.Odbc.OdbcConnectionHandle..ctor(OdbcConnection connection, OdbcConnectionString constr, OdbcEnvironmentHandle environmentHandle)
at System.Data.Odbc.OdbcConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.Odbc.OdbcConnection.Open()
at Microsoft.Practices.EnterpriseLibrary.Data.Database.GetNewOpenConnection()
at Microsoft.Practices.EnterpriseLibrary.Data.Database.GetOpenConnection(Boolean disposeInnerConnection)
at Microsoft.Practices.EnterpriseLibrary.Data.Database.GetOpenConnection()
at Microsoft.Practices.EnterpriseLibrary.Data.Database.LoadDataSet(DbCommand command, DataSet dataSet, String[] tableNames)
at Microsoft.Practices.EnterpriseLibrary.Data.Database.LoadDataSet(DbCommand command, DataSet dataSet, String tableName)
at Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteDataSet(DbCommand command)
at ReportSCS.Test.Program.Main(String[] args) in C:\Documents and Settings\bderiot\My Documents\Visual Studio 2005\Projects\ReportSCS\ReportSCS.Test\Program.cs:line 20

This is the code :

using System;
using System.Data;
using System.Data.Common;
using Microsoft.Practices.EnterpriseLibrary.Data;

namespace ReportSCS.Test
{
class Program
{
static void Main(string[] args)
{
for (int i = 0; i < 3000; i++)
{
try
{
Database datab = DatabaseFactory.CreateDatabase("REC");
DbCommand cmd = datab.DbProviderFactory.CreateCommand();
cmd.CommandText = "Select TOP 1 * FROM tbissuer";

DataSet ds = datab.ExecuteDataSet(cmd);
Console.Write(" " + i);
}
catch (Exception ex)
{
Console.WriteLine("Error at line " + i + " : " + ex.Message);
Console.ReadLine();
}
}
}
}
}


Very simple, the error occurs at about 2000 requests.
The main problem is that this it doesn't happen on other machines, we tried on 3 other whitout succeeding in reproducing the exception.
I'm not sure that EntLib is responsible for that, my sybase driver may be faulty even it is the same than on the other machines of my team.

If you have an idea, I take it ;)

Thx,
Bertrand



Dec 24, 2007 at 5:23 PM
We had a similar issue with the connection pools, try cleaning up your connections:

by adding logging similar to:

if cmd.Connection == Open
cmd.Dispose()
end

Also dispose of your dataset when it is finished with.

Our issue was because we were not disposing of active transactions and fully closing open Database connections.

Cheers,
Gavin