-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elli,
On 10/26/2009 10:59 PM, Elli Albek wrote: > To disable caching in DBCP, use configuration option: > poolPreparedStatements=false Note that this is the default. Presumably, if you don't know if your prepared statements are being cached, then they are not being cached. [Side note: MySQL users should be aware that enabling server-side prepared statements on your connections will almost certainly result in disaster. See MysQL's bug database and Connector/J changelog for more information.] > I don’t remember where exactly you specify it In your <Resource> definition in context.xml/appName.xml/server.xml > This is actually something that I would like > to see built into Tomcat/DBCP (property file configuration). Your system > admin will thank you. It is built into Tomcat. Just read the docs for JDBC DataSources: http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html Though not specifically mentioned, any attribute set on the <Resource> element in your XML will be set on the DataSource that gets created. That includes things like logAbandoned, poolPreparedStatements, defaultTransactionIsolation, etc. > It may not be possible to use the mysql caching algorithms, since they may > use features that are not publicly available through JDBC and are part of > their protocol. I don’t know the source well enough to comment on how it > works internally. Also, the Connector/J code itself is released under the GPL which may or may not be compatible with the APL. > Specific example of leaks: > 1. Close tomcat > 2. Connection pool is removed. > 3. Request comes in to the war file (the one that is in the closing > process) > 4. Request gets processed. > 5. Servlet needs a connection from DBCP. > 6. Tomcat does not find the DBCP pool in JNDI, so it recreates it. > 7. The newly created connection pool will not be used after this request, > and will not be closed. If the pool pings the connection, it will stay open. My understanding was that: 1. Tomcat does not remove the connection pool 2. Once the shutdown process has started, no new requests will be handled by the currently-shutting-down context Could these two items give the result you are observing? It's easy enough to have your webapp close the DataSource (even though it's kinda stupid that Tomcat doesn't do it for you). > After all this work, we just shut down tomcat when we update war files. I would always advocate this approach IMHO: just in case you've damaged your server at some point, starting fresh with a new deployment is a good idea. > 2. Call shutdown callbacks of different APIs, give developer an option to > deal with it. For example JMX shutdown process does not happen correctly. Please log a bug for any legitimate complaints that you may have. Remember that Tomcat shouldn't shut down anything that the webapp itself started. > We got to the > conclusion that shutting down objects in tomcat was little chaotic and no > one could say in confidence that using a certain listener API will work > better than another without spending a few days of tracing the code and > doing lots of tests. The servlet specification makes it clear which listeners should be notified of various events in a very specific order. If Tomcat is not following these criteria, there's a bug somewhere and you should report it. If you are using Tomcat-specific listeners, they should be properly documented and working per the docs. If they are not, please file a bug and help get things fixed. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrnTD8ACgkQ9CaO5/Lv0PBR3ACeNHW25/eOTWp7F905j7nwBVBF nJ4AoJDxZKGAAD0MwBvZipyPV7lCOATi =Cle2 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
