On 10/11/2010 06:51, sasidhar prabhakar wrote: > 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
Shall we guess what you set it to? My guess is "7". Am I right? What else did you change? p > On Tue, Nov 9, 2010 at 5:22 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
0x62590808.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
