Have u set up you logs to verify that your 'select 1' query is actually being run?
On Saturday, March 5, 2011, Dave Newton <davelnew...@gmail.com> wrote: > If this question is related to hibernate it'd be more efficient and > appropriate to ask on a hibernate-related list probably. > > Dave > On Mar 5, 2011 3:32 AM, "abhishek jain" <abhishek.netj...@gmail.com> wrote: >> hi, >> thanks for the mail, >> i tried this but the problem still persists, i added the context.xml file > in >> META-INF and the database information was not being picked from there. >> Also i added the connect-timeout parameter in my.cnf file in the mysqld >> section, but still the the timeout was after 8 hours of inactivity. >> >> I will appreciate if one can tell me exactly what to do, pl consider me a >> newbie and will appreciate if the instructions be given. >> >> thanks >> abhishek >> >> On Tue, Mar 1, 2011 at 3:26 PM, Maurizio Cucchiara < >> maurizio.cucchi...@gmail.com> wrote: >> >>> I struggled with this issue for a long period, at the end I reached a >>> good point: I started using database connection pools [1]. >>> Actually you should wait until the mysql connection dies (it should be >>> after 8 hours of db inactivity ), but you could change the >>> connect-timeout=seconds [2] in order to achieve the before mentioned >>> scenario. >>> >>> [1] http://commons.apache.org/dbcp/ >>> [2] http://dev.mysql.com/doc/refman/5.5/en/mysql-options.html >>> >>> >>> Here my context.xml is: >>> >>> <Context >>> override="true" >>> reloadable="false" >>> unpackWARs="true" autoDeploy="true" >>> liveDeploy="false" allowLinking="true"> >>> <!-- >>> maxActive=10 >>> Don't set this any higher than max_connections on your >>> MySQL server, usually this should be a 10 or a few 10's >>> of connections, not hundreds or thousands >>> --> >>> <!-- >>> maxIdle=5 >>> You don't want to many idle connections hanging around >>> if you can avoid it, only enough to soak up a spike in >>> the load >>> --> >>> <!-- >>> validationQuery=select 1 >>> Don't use autoReconnect=true, it's going away eventually >>> and it's a crutch for older connection pools that couldn't >>> test connections. You need to decide whether your application >>> is supposed to deal with SQLExceptions (hint, it should), and >>> how much of a performance penalty you're willing to pay >>> to ensure 'freshness' of the connection >>> --> >>> >>> <!-- >>> testOnBorrow=true >>> The most conservative approach is to test connections >>> before they're given to your application. For most applications >>> this is okay, the query used above is very small and takes >>> no real server resources to process, other than the time used >>> to traverse the network. >>> >>> If you have a high-load application you'll need to rely on >>> something else. >>> --> >>> <!-- >>> testWhileIdle=true >>> Otherwise, or in addition to testOnBorrow, you can test >>> while connections are sitting idle >>> --> >>> <!-- >>> timeBetweenEvictionRunsMillis=10000 >>> You have to set this value, otherwise even though >>> you've asked connections to be tested while idle, >>> the idle evicter thread will never run >>> --> >>> <!-- >>> minEvictableIdleTimeMillis=60000 >>> Don't allow connections to hang out idle too long, >>> never longer than what wait_timeout is set to on the >>> server...A few minutes or even fraction of a minute >>> is sometimes okay here, it depends on your application >>> and how much spikey load it will see >>> --> >>> <!-- >>> maxWait >>> Maximum time to wait for a dB connection to become available >>> in ms, in this example 10 seconds. An Exception is thrown if >>> this timeout is exceeded. Set to -1 to wait indefinitely. >>> --> >>> <!-- >>> removeAbandoned=true >>> >>> A database connection pool creates and manages a pool of >>> connections to a database. Recycling and reusing already >>> existing connections --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
