I'm not sure this is a Devart issue or not, but I thought I'd check to see if anyone else is seeing this behavior.
We have a WCF service app (hosted as a windows service), running on two windows 2008 R2 servers, that connects to an Oracle cluster. This morning we started getting "OCI Invalid Handle" errors from one of the servers running the WCF service app. The interesting piece of this is the very first error...
Message: Server did not respond within the specified timeout interval
Stack Trace: at Devart.Data.Oracle.a3.a(z A_0, ai A_1)
at Devart.Data.Oracle.OracleInternalConnection..ctor(z connectionOptions, OracleInternalConnection proxyConnection)
at Devart.Data.Oracle.cs.a(k A_0, Object A_1, DbConnectionBase A_2)
at Devart.Common.DbConnectionFactory.a(DbConnectionPool A_0, k A_1, DbConnectionBase A_2)
at Devart.Common.DbConnectionPool.a(DbConnectionBase A_0)
at Devart.Common.DbConnectionPool.GetObject(DbConnectionBase owningConnection)
at Devart.Common.DbConnectionFactory.a(DbConnectionBase A_0)
at Devart.Common.DbConnectionClosed.Open(DbConnectionBase outerConnection)
at Devart.Common.DbConnectionBase.Open()
at Devart.Data.Oracle.OracleConnection.Open()
at Platform.DataAccess.RFConnection.Open()
Then, we get this error for every command sent to the database, until the app is restarted.
Message: OCI invalid handle.
Stack Trace: at Devart.Data.Oracle.ah.b(Int32 A_0)
at Devart.Data.Oracle.a3.d()
at Devart.Data.Oracle.OracleInternalConnection.Commit()
at Devart.Data.Oracle.OracleConnection.Commit()
at Platform.DataAccess.RFConnection.Commit()
The service continued to throw the "OCI Invalid Handle" errors until we restarted it. Now it's running fine without errors. The timeout is likely due to a database server issue. But, the thing that concerns me is the OCI errors continued happening until we restarted the application.
Has anyone seen this behavior? Why would the timeout error cause all of these OCI errors?
Thanks!
OCI Invalid Handle error
-
- Devart Team
- Posts: 2420
- Joined: Wed 02 Nov 2011 09:44
Re: OCI Invalid Handle error
The process of connection establishment in the OCI mode cannot be interrupted, this is why after the error "Server did not respond within the specified timeout interval" the connection will continue establishing. We advise you to use the 'Connection Timeout=0' property for the connection string.
Re: OCI Invalid Handle error
Devart documentation for the Connection Timeout property says "A value of 0 indicates no limit, and should be avoided in a ConnectionString because an attempt to connect will wait indefinitely.". http://www.devart.com/dotconnect/oracle/docs/
I don't understand because i don't want it to continue, I want it to throw an error and drop the connection.
So, why would I set it to 0 when I want it to stop trying and drop the connection?
I don't understand because i don't want it to continue, I want it to throw an error and drop the connection.
So, why would I set it to 0 when I want it to stop trying and drop the connection?
-
- Devart Team
- Posts: 2420
- Joined: Wed 02 Nov 2011 09:44
Re: OCI Invalid Handle error
This description is created for the Direct mode. In the OCI mode, behaviour of Connection Timeout=0 differs a bit. As Oracle Client does not allow using Connection Timeout, we are using a workaround. We create a separate thread and create a new connection in this thread. If connection cannot be performed during the specified Connection Timeout, an exception is thrown. But the thread remains alive for some time and connection is still being established.dhoenig wrote:Devart documentation for the Connection Timeout property says "A value of 0 indicates no limit, and should be avoided in a ConnectionString because an attempt to connect will wait indefinitely.". http://www.devart.com/dotconnect/oracle/docs/
Re: OCI Invalid Handle error
OK. So, does Connection Timeout=0 in OCI mode act the same and wait for the connection for an unlimited amount of time?
-
- Devart Team
- Posts: 2420
- Joined: Wed 02 Nov 2011 09:44
Re: OCI Invalid Handle error
In case of CommandTimout = 0 for an OCI connection mode we do not control the OCI and do not set any time restrictions for it. It desides itself how soon the attempt should be interrupted.