On Thu, Dec 19, 2013 at 2:21 PM, Ron Lindhoudt <rlindho...@yahoo.com> wrote:
> Hi Andrea,
>
Hi Ron,
please try to avoid sending private mails and keep the traffic on the
mailing list instead,
I receive a lot of mail and if I get out for work a few days, or just too
busy with paid work,
these private ones simply get forgotten.
>
> First I didn't get it working using *org.apache.tomcat.jdbc.pool *
> Now I got it working with org.apache.commons.dbcp.BasicDataSource.
> Is it correct that *org.apache.tomcat.jdbc.pool is not supported for
> GeoTools?*
> *You mentioned only dbcp pool in your previous mail.*
>
> I read that common dbcp has some drawbacks:
>
> http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Getting_the_actual_JDBC_connection
> -----------------
> So why do we need a new connection pool?
> Here are a few of the reasons:
>
> 1. commons-dbcp is single threaded, in order to be thread safe
> commons-dbcp locks the entire pool, even during query validation.
> 2. commons-dbcp is slow - as the number of logical CPUs grow, the
> performance suffers, the above point shows that there is not support for
> high concurrency Even with the enormous optimizations of the
> synchronized statement in Java 6, commons-dbcp still suffers in speed
> and concurrency.
> 3. commons-dbcp is complex, over 60 classes. tomcat-jdbc-pool, core is
> 8 classes, hence modifications for future requirement will require much
> less changes. This is all you need to run the connection pool itself, the
> rest is gravy.
> 4. commons-dbcp uses static interfaces. This means you can't compile
> it with JDK 1.6, or if you run on JDK 1.6/1.7 you will get
> NoSuchMethodException for all the methods not implemented, even if the
> driver supports it.
> 5. The commons-dbcp has become fairly stagnant. Sparse updates,
> releases, and new feature support.
> 6. It's not worth rewriting over 60 classes, when something as a
> connection pool can be accomplished with as a much simpler implementation.
> 7. Tomcat jdbc pool implements a fairness option not available in
> commons-dbcp and still performs faster than commons-dbcp
> 8. Tomcat jdbc pool implements the ability retrieve a connection
> asynchronously, without adding additional threads to the library itself
> 9. Tomcat jdbc pool is a Tomcat module, it depends on Tomcat JULI, a
> simplified logging framework used in Tomcat.
> 10. Retrieve the underlying connection using the
> javax.sql.PooledConnection interface.
> 11. Starvation proof. If a pool is empty, and threads are waiting for
> a connection, when a connection is returned, the pool will awake the
> correct thread waiting. Most pools will simply starve.
>
>
Yes, yes, well known... and also mostly irrelevant until recently, at least
in GeoServer usage,
because the scalability bottleneck in Oracle JDK Graphics2D is much worse
that whatever
commons-DBCP is causing (we made tests a couple of years ago with Tomcat's
own
pool, did not make a difference in WMS benchmarks).
Now, I believe in the meantime the Tomcat one has improved, and we have
recent developments
that might make it worth re-evaluating as the other scalability issues are
becoming less of a problem:
http://osgeo-org.1560.x6.nabble.com/Faster-PNG-encoder-some-WMS-tests-td5083309.html
http://osgeo-org.1560.x6.nabble.com/New-PNG-encoder-OpenJDK-7-Woot-td5084608.html
The issue with Oracle database is that we need to access the native Oracle
connection to read
the geometries, thus, we need to "unwrap" the pooled connection.
In GeoTools we have an unwrapper for DBCP already registered, but not one
for the Tomcat
connection pool, which is instead available in GeoServer (as far as I
remember) thanks
to the Spring library (the Spring DBCP unwrapper officially handles the
tomcat pool as well):
https://github.com/geoserver/geoserver/blob/646480bcc069464bc45600a5f4c59e4293513b77/src/main/src/main/java/org/geoserver/data/jdbc/SpringUnWrapper.java
and registered in SPI here:
https://github.com/geoserver/geoserver/blob/646480bcc069464bc45600a5f4c59e4293513b77/src/main/src/main/resources/META-INF/services/org.geotools.data.jdbc.datasource.UnWrapper
So, to use that pool, you'll have to write a similar bit of code in your
application (or just use
the Spring based one, if you have Spring in your classpath
Hope this helps
Cheers
Andrea
--
*== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014 ==*
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
