-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bradley,
On 10/7/15 4:04 PM, Bradley Wagner wrote: >> The general recommendation is to use the default pool >> (commons-dbcp). > > Great. Thanks! > >> Unless you have narrowed a performance problem to the pool >> itself, > there's no reason to use one over the other. I suspect that there > are only a few companies in the world where the connection pool > implementation's overhead makes a noticeable difference in the > performance of their web applications. >> Not doing a million transactions a minute? Don't worry about a >> thing. > > Nope. Thanks! > >> Of course. No component is going to guess that the number you put >> in > configuration (5000) should be applied to some other setting. > > Right, understood. In a previous message int his thread, Mark had > speculated that perhaps the factory was mapping the param to the > right name under the covers. This logging confirmed that the param > was just being ignored. Right: for the transition for commons-dbcp1 -> commons-dbcp2, we have mapped certain common fields to help easy the transition process. Anything that issues a complaint in the log file is surely being ignored . >> I think this has more to do with the tolerance of the Spring > configuration component relative to the tolerance of the Tomcat > configuration component: both are creating a new DataSource and > calling setFoo() on them, but only Spring fails when a setter is > not available, while Tomcat just gives a warning and continues on > its way. > > Yep, that makes sense. Was looking for a warning in the Tomcat > logging but didn't see that either. I think that's another source of confusion: Tomcat has re-mapped those fields, but it doesn't magically do it for other components like Spring. Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWFqPcAAoJEBzwKT+lPKRYpP4QAMZvB7WLjxoONMYyMQ0tq/no BuBfq5uk+xd09XIdCdMW66rvC63s9fPqwud6hnBB++yh3HQaFy+iqLHsbO2sLYkp obiuEw4vVg2QrlHKJW1kvO8w4HoT1rytF5iR99ejxErEWbQRBm+Vkq7TmRE71nXu ANYhEC08+DdnRaLhFPI7pSTAIOd2JQSeWqdytl4hNlBaiKqs3H1W69Y8qSSatW/P v0ZNYArz5l1C3o4I07bGqEbWl1NGpmdciYldV3ZdxAXrW13MshLZu9Jw0BOjxTUW Nt5PaunBbM554YD8cfs9kid+fQ380ZwuKpjAPP/2XHmuoVZt9Wm+kSXJO3b+ASgA uzB3jYSTYnqURKZNXwwI8xoJaMxMrLd3WvLI5DB9iC/lO9aWwvuFHVNqHDOGXKiz xemu54LZY2XL6KLgR0I5h4cH/2f2c2eK2ybce7ndNtpuzSrc6VUg/oaW4sJWOceS v3qchS2kT28DaMWbgV9p5OJKby9yKdZFdLs8glD3CL7+yrFfD0zHnrB1eQKDwrhL RgHKHTwvS8YlvQ3iroWqwlw9kcoZBv3anu4izvLW/USOiBQ27/y65WGaYmsaG+Xl /AcwMP/6vvWCqB35atnWu6MrdLM9gI9YZeTfExUlHr9HHYGMH3oRhfr+bAhY/eFl 7exTSYPw24xwUtsMqCr4 =LSZ3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
