After changing time out value now I am getting this problem org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot get a connection, pool error Timeout waiting for idle object
On Tue, Nov 9, 2010 at 5:22 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sasidhar, > > On 11/8/2010 12:31 AM, sasidhar prabhakar wrote: > > On Thu, Nov 4, 2010 at 9:10 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > >> > >> I have found that these exceptions can occur even when there is no leak. > >> > >> Specifically, if your SQL query takes a long time to run (that is, more > >> than the ababdonedTimeout), another request to the connection pool > >> complains about the connection and calls it abandoned. > >> > > > > I think your right. Timeout I mentioned 30sec deafault is 300sec. This > is > > my context.xml > > > <?xml version="1.0" encoding="UTF-8"?> > > <Context path="" > > > "path" is not allowed in context.xml: remove it. > > > validationQuery="SELECT * from dual" > > SELECT *? Wow. How about "SELECT 1 FROM dual"? > > > testOnBorrow="true" > > removeAbandoned="true" > > removeAbandonedTimeout="30" > > That's a 30-second abandoned timeout. > > > username="scott" > > password="*******" > > "tiger", right? > > >> Technically speaking, the connection hasn't been leaked, but the > >> connection pool can't really guess the reason why the connection hasn't > >> been returned. > >> > >> Can you time your queries to see how long they take? Could you post your > >> <Resource> configuration for your DataSource? > > > > For some queries it took more than 30 seconds, from getting data from > > ip_to_geo table, which has 3 million rows in it. > > That could be your problem: you should probably increase your > removeAbandonedTimeout value to something more appropriate for your > application. > > You might also want a dba to check out your queries and your database > structure. 3 million rows isn't that much, even for Oracle :) > > >> Another note: I notice that you are using a DataSource object that > >> survives for the life of the DAO object, and is even created by the > >> object in its constructor. > > > > Every DAO has only one instance for the entire life of application. Is > this > > correct approach. So Every thread accessing the same datasource object to > > get connection. > > It was just a recommendation which gives you flexibility: your webapp > (or the container, etc.) has the freedom to discard and completely > re-build the DataSource for your webapp if you always go to the JNDI > context to get the DataSource. Otherwise, you will force a webapp > restart just to get a new DataSource. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkzZ180ACgkQ9CaO5/Lv0PDicACfZ/rv+FN8cT8JATK2ZlGYgWUW > CPoAn2/j0NO6af4RuL9t7j4yH9wXP+bW > =l181 > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
