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.koli...@gmail.com>
> > wrote:
> >
> >> 2015-10-07 21:36 GMT+03:00 Bradley Wagner <
> bradley.wag...@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-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> 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>
