> 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.
> 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.
On Wed, Oct 7, 2015 at 3:51 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Bradley,
>
> On 10/7/15 3:21 PM, Bradley Wagner wrote:
> > Ah, I see what you're saying. My apologies for not seeing that
> > sooner.
> >
> > That post was also very helpful in explaining why both exist.
> > Thank you!
>
> It's definitely confusing to those you don't already understand.
> "DBCP" usually just means "database connection pool", but in the
> Apache world, it usually specifically means commons-dbcp.
>
> > Is it your recommendation then to use DBCP 2 over Tomcat JDBC in
> > Tomcat 8? If so, I think it would be helpful to have a page on the
> > public Tomcat website about why both exist and which one is
> > recommended.
>
> The general recommendation is to use the default pool (commons-dbcp).
>
> 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.
>
> > Also, in my case, after some more digging, I found that Tomcat JDBC
> > was simply ignoring my badly named params. I had specified
> > maxWaitMillis="5000" in my <Resource> in context.xml. Yet on
> > initialization, I saw the following in my log:
> >
> > Using DataSource
> > [org.apache.tomcat.jdbc.pool.DataSource@41a91006{ConnectionPool[defaul
> tAutoCommit=null;
> >
> >
> defaultReadOnly=null; defaultTransactionIsolation=-1; defaultCatalog=nul
> l;
> > driverClassName=com.mysql.jdbc.Driver; maxActive=100; maxIdle=10;
> > minIdle=10; initialSize=10; maxWait=30000; testOnBorrow=true;
> > testOnReturn=false; timeBetweenEvictionRunsMillis=5000;
> > numTestsPerEvictionRun=0; minEvictableIdleTimeMillis=60000;
> > testWhileIdle=false; testOnConnect=false; password=********;
> > url=jdbc:mysql://localhost:3306/<REDACTED>?useUnicode=true&characterEn
> coding=UTF-8;
> >
> >
> username=root; validationQuery=SELECT 1; validationQueryTimeout=-1;
> > validatorClassName=null; validationInterval=30000;
> > accessToUnderlyingConnectionAllowed=true; removeAbandoned=false;
> > removeAbandonedTimeout=300; logAbandoned=true;
> > connectionProperties=null; initSQL=null; jdbcInterceptors=null;
> > jmxEnabled=true;
> >
> > which shows maxWait=30000.
>
> Of course. No component is going to guess that the number you put in
> configuration (5000) should be applied to some other setting.
>
> > So it looks Tomcat JDBC is forgiving with badly named params in
> > that it doesn't fail on startup. Whereas if I try to instantiate a
> > Tomcat JDBC DataSource directly, it fails when I try to set
> > properties that don't exist.
>
> 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.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWFXeZAAoJEBzwKT+lPKRY9RcP/iAu93Ib07WtvMru0ZCE8lFR
> ugWRHtXAnYs1AhwAFIKgGxOuQfnOSmY7ycHBVZSINfv+T9roSyFrgOq9/EMdM2Nj
> YyEsnxUtcGEyHFkDuwYDHhIE7u6hrXrXy4yNj/Ilsjlau8wjlah2yiDQgumES0m8
> E9N6QhLApXI+wvBPEJkBCWhxBfa5z50y9oXFVDrrnSZmynHiEzpBgx+bKaoJjeeh
> xUUg2ddLuJLONkWnvXnimkppjcdOfryIprtFeMjuLFr/DowyPXb3fC9lMGwJqmpc
> dSFNO8iMAfPVwX7LDyv1swGmMFG79HUb74GMlnFQhXH09f0CHVifSn/n9n5Oyf5M
> sOSvMCvdzb+c8rwuuJb0T6qDtZg+4BVDUSv7Mw6zHBUp4BTdFfdPuWlbwlHDO2Ed
> gDirhHe2lECyScTx4vKVzZGRgLvArF+IY+EM5LHgP4FugC+0eUDoMmE2vVoI/TSt
> Y7uQTd9BqbaXViAcDP/8vjiWBnVbrnOgW4jdSZyIforE2QnD3oq6H5JZFTfNfEQt
> WG2KY7kOpF6JZ5BwDIqFoM2N9/Ywz9Wy42VzGsiP65sVDAEDlnAeysa2icsV9L3l
> 4Sk69mEJXsokcbzEiHkL+LwXf8DNl0Rw53Kk9SEOhNeICb+emQnMnaMBhndEX5ZW
> 8kudLYhkwjagMFl6hB+F
> =I0lL
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> --
Bradley Wagner
VP Engineering, Hannon Hill
www.hannonhill.com | Twitter <https://twitter.com/hannon_hill> | Github
<http://github.com/hannonhill>
