You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bradley Wagner <br...@hannonhill.com> on 2015/10/07 21:21:06 UTC
Re: DBCP params different for the Tomcat JDBC (not DBCP)
implementation in Tomcat 8?
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!
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.
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[defaultAutoCommit=null;
defaultReadOnly=null; defaultTransactionIsolation=-1; defaultCatalog=null;
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&characterEncoding=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.
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.
Thanks again,
Bradley
On Wed, Oct 7, 2015 at 3:09 PM Mark Thomas <ma...@apache.org> wrote:
> On 07/10/2015 19:54, Bradley Wagner wrote:
> > Did not what?
> >
> > We added "factory='org.apache.tomcat.jdbc.pool.DataSourceFactory'". That
> > switched us to Tomcat DBCP, correct?
>
> No. There is no such thing as Tomcat DBCP.
>
> There is Apache Commons DBCP 1. This is used by default in Tomcat 6.0.x
> and 7.0.x.
>
> There is Apache Commons DBCP 2. This is used in default Tomcat 8.0.x.
>
> Commons DBCP is packaged renamed to avoid class loading conflicts if the
> web application includes a copy of Commons DBCP in WEB-IN/lib.
>
> There is also the Tomcat JDBC connection pool. This is entirely separate
> from DBCP. For the full history, read this [1].
>
> > At that time, we were using the updated "maxWaitMillis" and "maxTotal" in
> > our context.xml and Tomcat didn't seem to complain on startup.
> >
> > Then, when we tried to set "maxWaitMillis" on a manually created Tomcat
> > DBCP dataSource:
> > "<bean id="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource"
> > destroy-method="close">" in a test at which point we got an error about
> > that class not having a 'maxWaitMillis' setter.
> >
> > Was the Tomcat DBCP we were using in our context.xml just failing
> silently
> > or ignoring the 'maxWaitMillis' and 'maxTotal' params and we didn't
> realize
> > it?
>
> I suspect Tomcat was changing the names as required under the covers
> without telling you anything.
>
> > Are the params here:
> > https://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html mean to be the
> > definitive ones for Tomcat DBCP?
>
> Those are for Tomcat JDBC. There is no Tomcat DBCP.
>
> Mark
>
>
> [1] http://markmail.org/message/nhayhdcstkj2lssf
>
> >
> > On Wed, Oct 7, 2015 at 2:46 PM Konstantin Kolinko <
> knst.kolinko@gmail.com>
> > wrote:
> >
> >> 2015-10-07 21:36 GMT+03:00 Bradley Wagner <
> bradley.wagner@hannonhill.com>:
> >>> Hi,
> >>>
> >>> We recently upgraded to Tomcat 8. As per the Migration Guide:
> >>> https://tomcat.apache.org/migration-8.html#Database_Connection_Pooling
> >> and
> >>> DBCP documentation
> >>>
> >>
> https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html#Database_Connection_Pool_(DBCP_2)_Configurations
> >> ,
> >>> we switched to using the new param values like: maxTotal and
> >> maxWaitMillis.
> >>>
> >>> Then, we switched to using the Tomcat DBCP by adding
> >>> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory". Tomcat did not
> >>> seem to have a problem with using Tomcat DBCP with the updated param
> >> names.
> >>
> >> No, you did not. The above factory is for "Tomcat JDBC" pool
> >> implementation.
> >>
> >> It was inspired by DBCP1, but is different from both Commons DBCP1
> >> (used by default in Tomcat 6, 7) and Commons DBCP2 (used by default in
> >> Tomcat 8).
> >>
> >>> Then, I modified a test we were running to also use a Spring
> >> initialized,
> >>> Tomcat DBCP DataSource:
> >>>
> >>> <bean id="dataSource" class="org.apache.tomcat.jdbc.pool.DataSource"
> >>> destroy-method="close">
> >>>
> >>> Now, our test is complaining with: "Bean property 'maxWaitMillis' is
> not
> >>> writable or has an invalid setter method." because we were using the
> new
> >>> style param name:
> >>>
> >>> <property name="maxWaitMillis" value="5000"/>
> >>>
> >>> So now I'm confused.
> >>>
> >>> 1. Does Tomcat DBCP (in Tomcat 8) indeed use different params than the
> >> new
> >>> DBCP2 that ships with Tomcat 8?
> >>> 2. Why did Tomcat not complain when I was using maxWaitMillis with the
> >>> updated factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" but
> does
> >>> complain when I try to instantiate that pool implementation's
> DataSource
> >>> directly?
> >>> 3. Is there some other way that I should be instantiating the Tomcat
> DBCP
> >>> DataSource in my test that would be more appropriate?
> >>>
> >>> I searched the archives and couldn't find mention of this.
> >>>
> >>> Thanks!
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> --
Bradley Wagner
VP Engineering, Hannon Hill
www.hannonhill.com | Twitter <https://twitter.com/hannon_hill> | Github
<http://github.com/hannonhill>
Re: DBCP params different for the Tomcat JDBC (not DBCP)
implementation in Tomcat 8?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP params different for the Tomcat JDBC (not DBCP)
implementation in Tomcat 8?
Posted by Bradley Wagner <br...@hannonhill.com>.
> 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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> --
Bradley Wagner
VP Engineering, Hannon Hill
www.hannonhill.com | Twitter <https://twitter.com/hannon_hill> | Github
<http://github.com/hannonhill>
Re: DBCP params different for the Tomcat JDBC (not DBCP)
implementation in Tomcat 8?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org