Hi, I've updated the connection pooling http://docs.codehaus.org/display/GEOTOOLS/Connection+pool+subsystem+upgrade
Here are some notes on the implementation of the secondary SPI. As usual, actually triying to implement the stuff showed up some controversial points. Let's say I'm setting up a generic DBCP DataSource. This means I have to provide (some of) the parameter listed here: http://jakarta.apache.org/commons/dbcp/configuration.html Two of the primary parameters are url and driverClassName. For postgres, for example, it would mean the user has to put in values such as: driverClassName=org.postgresql.Driver url=jdbc:postgresql://localhost/dbname This can be seen as a regression compared to the old system, since when we did setup a postgis data store, the format of the url and the driver class names where known, whilst setting up a generic DBCP connection pool, they are not. Yet being able to specify the URL is in some rare cases a must, for example some months ago a user had lots of troubles setting up Geoserver because he had to setup an SSL connection to Postgres, and our "easy to use" configuration would not allow that (he would have succeded if he could specify the url). I know this sounds complicated, yet in my years working at SATA I have used, in different occasions, every single config parameter that DBCP provided me, and that happened every time my apps were to be connected to a central db administered by a full time DBA. Those DBA have to ensure that no rougue application can ruin the operation of the other apps and the central db, so they do setup various kind of limitations on what an app can do, such as, you cannot use more than 7 connections, a connection cannot be idle for more than 1 minute, you cannot open more than 20 prepared statements per connection, and so on. To make the application work within those limitations, fine tuning the connection pool is really a make or break. I guess having two factories per datastore, one with the old interface (datastore specific, asks for host, username, pw, and eventually just the max connection number, and uses dbcp internallY) and one that accepts a generic DataSource setup with the DataSourceFactorySPI with the extra complication of setting up a fully generic connection pool should fit most requirements. If you feel like voting the proposal, do so, otherwise, feedback appreciated. Ah, implementation wise, since we have to switch all datastores in one shot, shall we try and do the switch in a short lived branch? Cheers Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
