-----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
