Yes, but did you actually ever bother to read its documentation, e.g. at http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html ?
> (particularly starting with the attribute "testOnBorrow") > > I do not know much about these things, but just entering > ""org.apache.tomcat.jdbc.pool" in Google, and reading that documentation > leads me to believe : > - that there are N database connections in the pool > - that they can be checked regularly in the background for validity, > - that a non-valid connection automatically gets dropped from the pool, and > replaced by a new one when needed > - that you can pretty much set any aspect of that mechanism by those > attributes > - and that you can log what happens > Yes, I've read the documentation. connections can be checked - yes, I know, this is the validation string I can add in the xml file, but as I said - It has affected our production environment when using it (although we used it at the time with the dbcp pool and not the JDBC pool), so I prefer not to go there. log- I have written down the log I get in my initial post. > > So, if you are using that pool, I basically do not understand why you would > need any additional mechanism to overcome the loss of a db connection when > your VM is migrated. > Particularly that "smart keep alive" you keep talking about, but never > telling us where it comes from and where it is inserted in that > architecture. > > I don't understand on what mechanism are you talking about. I don't want to add anything (unless it can fix the problem) I just stated the problem, and the environment we have (win 2008, tomcat 6.0.29, jdbc pool.. These are the dry facts) The keep alive is an xslt file which contains actions to perform on the DB to check that everything is alive. if so, it returns an OK response, which can be viewed in HTML file on IE browser. The Load balancer samples the keep alive every 10 seconds to check the OK state. if it's not OK for 3 times in a row- the LB takes it out from the servers' pool and no one else can connect to it. so yes. we need this keep alive and can't dismiss it, because it's the indication that the server is functioning properly. and if it's not function - The LB can identify it and remove the server from the servers' pool so no one will try and approach it. > > >> we use the JTDS driver (I tried the Microsoft JDBC, but its performance is >> poor compared to the JTDS driver of sourceforge) >> Someone in my company suggested that the problem can rely in either of >> these >> JARs. >> so I will check with the tomcat-dbcp.jar as scenario 1, sql-jdbc.jar as >> scenario2, and maybe both combined as scenario 3. >> scenario 4 will be testing the behavior while validation is configured. >> >> > Sure, add some extra variables to the problem. That will make it a lot > simpler to find out what happens. > > no need of sarcasm here. these aren't additional variables. we spoke on the connection pool, so this is one of the things I can focus on to try and fix the problem. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
