4 Replies Latest reply on Jul 9, 2014 8:24 AM by ChrisJenkins-Oracle

    My application received  [DataAccessConnectionManager] Connect DbException - Connection request timed out




         Yesterday we have executing some test on my timesten database. It has been working good, but some clients started to receive this errore message:


      [DataAccessConnectionManager] Connect DbException - Connection request timed out

      at Oracle.DataAccess.Client.OracleException.HandleErrorHelper(Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, String procedure, Boolean bCheck)

          at Oracle.DataAccess.Client.OracleException.HandleError(Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, Object src)


      My application is developed on C# and .NET

      My database version is


      I connected to database using direct method and ttisql directly on the server, database was good health. it had enough space disk even data and log files.it had enough space in memory, because it is defined 50G and pemanent in use was just 3G.


      I reviewed database logs, and I did not found any errore messages either ttmesg.log nor tterror.log files.

      From my point of view, according to my log files and error message, I think this client connection did not reaches database. This timeout error es reached before process could get a database connection, one more, this process did not leave client.


      But my doubt is because, application could connect once I restarted database. so if database was online, accepting connections, good on space even disk and memory, what could be the problem?. Even though database has many connections from many clients ....



        • 2. Re: My application received  [DataAccessConnectionManager] Connect DbException - Connection request timed out

          Are your ODP.NET clients connecting to TimesTen in direct mode or via client/server (I am guessing client/server)? What are your client side settings for TTC_TIMEOUT? Was the TT database actually loaded in memory when the clients tried to connect; if you have the default ramPolicy of inUse then the database gets loaded into memory from disk on the first application connection. If the database is large and./or your disks are slow then this could easily take longer than the TTC_TIMEOUT value resulting in the connection request timing out.


          I suggest that you:


          1.   Switch the database to ramPolicy 'manual and then use ttAdmin -ramLoad to explicitly start it up.


          2.   Check your settings for TTC_TIMEOUT on the clients (the default is 60 seconds).


          And of course, a network issue could also result in this kind of error.



          • 3. Re: My application received  [DataAccessConnectionManager] Connect DbException - Connection request timed out

            Thanks a lot for your answer Chris.


            Clients are connected by client/server.

            Database is set on rampolicy to "always", because set it on "in use" spent a lot of time connection.


            RAM residence policy: Always

            Replication policy  : Manual

            Replication agent is running.

            Cache Agent policy  : Manual

            PL/SQL enabled.


            Accessible by any group

            End of report



            TTC_TIMEOUT is set to 5 (secs) (because of the application response time)

            Disk are SAN DISK (emc)


            This is my database configuration.

            • 4. Re: My application received  [DataAccessConnectionManager] Connect DbException - Connection request timed out

              Hi Ricardo,


              Thanks for this information and also for the more comprehensive information that you provided offline. I have reviewed that and this looks to be a client side problem. There is no indication on the server side that there is any issue there, but the log messages


              2014-06-28 15:54:45.71 Err : SRV: 17617: EventID=5| Socket recv() failed. Error (104): Connection reset by peer. File: /ade/vespa_20120924_kaiser-tt/timesten/VisiChannel/oc/src/vostcpip.cpp; Line: 668


              indicate that the client side explicitly closed the connection while the server was waiting for a message from the client. This strongly suggests that there is some problem on the client side. Note that ODP.NET is a complex stack with several layers of which the TimesTen client is but a small part. It is certainly possible that there could be some issue with the TimesTen client but to my mind we should try and eliminate more general ODP.NET related issues first. I note that you have already seen this article about a problem with the same symptoms:



              Have you tried the steps listed in that to see if they reveal any issue on the ODP.NET side? There is some limited debugging we could try and perform for the TimesTen client but it uses undocumented mechanisms so I would need to discuss that with you offline.