G
Guest
I am developing a data access layer class derived from ServicedComponent in
managed C++ using VS2005 Beta2, and .NET 2.0. The class uses object pooling
and is JIT-enabled, with a Query method that returns a Dataset and is marked
AutoComplete.
This component has a reference to an inner OleDbConnection object that it
creates when it is constructed.
When a client in an different process connects to the component by
instantiating it, the component is actually created on the first Query method
call. The method returns OK and the component goes to the pool, as it should.
The next time the client makes a call, the component comes out of the pool,
gets to work, then goes back to the pool. This is all as it should be.
The problem happens when either the client destroys its reference (using
delete) and instantiates a new one and calls the Query method, or another
client instantiates the component while there is one in the pool and calls
the Query method. Either of these situations results in an E_NOINTERFACE
error being thrown from within ExecuteReader(). I have tried this with three
different providers: MSDOra, OraOLEDB, and TDOLEDB (Teradata) and two
different machines, and the results are the same. If I use OdbcConnection
instead of OleDbConnection it works fine. If I call other methods (like the
State property) of the OleDbConnection object, they work fine.
I think this is a problem with OledbConnection. My reasoning is that there
should be no way that the OledbConnection object, being inside my component
that is happily sitting in the COM+ object pool, should be able to
distinguish between a call from one remote serviced component proxy (RSCP)
versus another one. It should be stateless and remain blissfully unaware
whether the call came from one client or the other, but if I call it from a
different RSCP than the one that triggered its creation, it throws the
exception. I've also logged the thread id of the thread making the call but
it doesn't seem to matter.
Here is my connection string, notice I am turning off session pooling:
m_conn = gcnew
OleDb::OleDbConnection("Provider=MSDAORA.1;Password=XXXX;User ID=myuid;Data
Source=testsource;OLE DB Services=-4");
Here is the exception:
2005-10-11 17:09:42 5448 TestConnection failed with exception
System.Data.OleDb
..OleDbException: 'OraOLEDB.Oracle.1' failed with no error message available,
res
ult code: E_NOINTERFACE(0x80004002).
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForMultpleResults(tagDBPARAMS dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior
behavior, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader()
at t_COMPlus.TestDAL.TestConnection()
managed C++ using VS2005 Beta2, and .NET 2.0. The class uses object pooling
and is JIT-enabled, with a Query method that returns a Dataset and is marked
AutoComplete.
This component has a reference to an inner OleDbConnection object that it
creates when it is constructed.
When a client in an different process connects to the component by
instantiating it, the component is actually created on the first Query method
call. The method returns OK and the component goes to the pool, as it should.
The next time the client makes a call, the component comes out of the pool,
gets to work, then goes back to the pool. This is all as it should be.
The problem happens when either the client destroys its reference (using
delete) and instantiates a new one and calls the Query method, or another
client instantiates the component while there is one in the pool and calls
the Query method. Either of these situations results in an E_NOINTERFACE
error being thrown from within ExecuteReader(). I have tried this with three
different providers: MSDOra, OraOLEDB, and TDOLEDB (Teradata) and two
different machines, and the results are the same. If I use OdbcConnection
instead of OleDbConnection it works fine. If I call other methods (like the
State property) of the OleDbConnection object, they work fine.
I think this is a problem with OledbConnection. My reasoning is that there
should be no way that the OledbConnection object, being inside my component
that is happily sitting in the COM+ object pool, should be able to
distinguish between a call from one remote serviced component proxy (RSCP)
versus another one. It should be stateless and remain blissfully unaware
whether the call came from one client or the other, but if I call it from a
different RSCP than the one that triggered its creation, it throws the
exception. I've also logged the thread id of the thread making the call but
it doesn't seem to matter.
Here is my connection string, notice I am turning off session pooling:
m_conn = gcnew
OleDb::OleDbConnection("Provider=MSDAORA.1;Password=XXXX;User ID=myuid;Data
Source=testsource;OLE DB Services=-4");
Here is the exception:
2005-10-11 17:09:42 5448 TestConnection failed with exception
System.Data.OleDb
..OleDbException: 'OraOLEDB.Oracle.1' failed with no error message available,
res
ult code: E_NOINTERFACE(0x80004002).
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS
dbParams, Object& executeResult)
at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForMultpleResults(tagDBPARAMS dbParams, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior
behavior, Object& executeResult)
at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior
behavior, String method)
at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior)
at System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader()
at t_COMPlus.TestDAL.TestConnection()