none
IDbCommand.ExecuteReader() never returns when previous conn/cmd/reader closed in worker thread RRS feed

  • Question

  • Hi all;

    I set up my code to close a connection in a worker thread. The code is as follows:

    if (!dataReader.IsClosed)
    	cmd.Cancel();
    if (connection.State == ConnectionState.Open)
    	if (!dataReader.IsClosed)
    		dataReader.Close();
    if (connection.State == ConnectionState.Open)
    	connection.Close();
    dataReader.Dispose();
    cmd.Dispose();
    connection.Dispose();
    

    And then elsewhere I have the standard:

    IDbConnection conn = provider.CreateConnection();
    conn.ConnectionString = connectionString;
    conn.Open();
    
    IDbCommand cmd = conn.CreateCommand();
    cmd.CommandType = CommandType.Text;
    cmd.CommandText = select;
    
    IDataReader reader = cmd.ExecuteReader();

    Where I am connecting to Northwind and requesting 30 rows. When I don't have the problem it returns instantly. But sometimes it never returns. It doesn't even timeout.

    If I change my close in the first block above to be called directly and not handled in a worker thread, then this problem does not occur.

    Is it possible that the close is occurring intermixed with my subsequent query - and that the connector is giving me objects from a pool that are not fully released?

    Also, the call:

    dataReader.Close();

    Sometimes throws an exception when called from the worker thread.

    ??? - thanks - dave


    Who will win The Windward International Collegiate Programming Championships?

    Friday, January 11, 2013 6:53 PM

Answers

  • No there should not be then if no state is shared. Because of "close a connection in a worker thread", I thought there is thread to create connection and another one to work with it.

    You don't have any exceptions that would be lost, empty catches or something else?

    • Marked as answer by DavidThi808 Monday, January 14, 2013 5:14 PM
    Saturday, January 12, 2013 4:35 PM

All replies

  • So the worker thread closes the connection, command and reader instances created in another thread, but who does the job with the instances? If threads might access those instances at same time, how have you manage thread synchronization?

    DbProviderFactory documentation says that new connection instance is returned, but of course inheritor might change this behavior.

    Saturday, January 12, 2013 8:10 AM
  • The two threads are using totally distinct IDbConnection, IDbCommand, & IDbReader objects. So there should be no need for thread synchronization. Or is there a need even if I have distinct objects?

    thanks - dave


    Who will win The Windward International Collegiate Programming Championships?

    Saturday, January 12, 2013 1:29 PM
  • No there should not be then if no state is shared. Because of "close a connection in a worker thread", I thought there is thread to create connection and another one to work with it.

    You don't have any exceptions that would be lost, empty catches or something else?

    • Marked as answer by DavidThi808 Monday, January 14, 2013 5:14 PM
    Saturday, January 12, 2013 4:35 PM
  • Your post made me think that we must have some reuse of the object. So I reviewed the code and did find how it could happen - so it was multiple threads using the same object.

    thanks - you


    Who will win The Windward International Collegiate Programming Championships?

    Monday, January 14, 2013 5:14 PM