Sounds reasonable with a quick read. I'm out of town this week but will take a more detailed look when I get back.
One of our customers had been asking for data source support a few months ago. David Andrea Aime wrote: > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
