Ack so much information! And I volunteered to help write it up ... Here is the first page: http://docs.codehaus.org/display/GEOTDOC/01+Use+of+DataSource
And the second: http://docs.codehaus.org/display/GEOTDOC/02+JDBC+DataStore+Example I will add to these pages as I understand what Andrea has written. Jody >> Hi all, >> I'm about to merge the datasource branch (see connection pooling work) >> so please, no changes until I'm done :) >> > > Ok, I've merged the changes. Please, everybody test this :) > > First of all, rebuild your geotools from scratch, and do > a mvn eclipse:eclipse, since new libraries are needed (DBCP). > > The, a short summary for everybody. ConnectionPool is still there, > deprecated, and all datastores are using DataSource instead. > > The default DataSource implementation can be built using > DataSourceUtil (so that you can build one easily from code), > and each JDBCDataStoreFactory has one new method, getDataSource(...) > so that if you know the database you're targetting, you don't > have to remember jdbc url format and driver name. > > All JDBCDataStoreFactory have been changed so that they have a > few new optional params to control the default connection pool, > notably, the min and max connection size, and wheter the connection > should be validated on borrow (to validate a connection, a quick > query, like "what time is it" is sent to the server, so it has > a cost, but allows to recover from database restarts without issues). > > A DataSourceFinder has been setup so that you can look for > DataSource implementations, and two implementations DBCPDataSource > and JNDIDataSource are available. > > Now, what remains to be done? Well, at the moment there are no > JDBC factories accepting a DataSource object instead of the > classic parameters, we have to create them (in order to support > JNDI connections). > One may argue that JNDI should be handled by the default datastore > factories, and I see the point, yet I'm wondering, should we > have multiple ways to setup the conection pool in the datasource? > I'd say no, because... well, the day we add a OC4J connection pool, > or a C3P0 connection pool, shall we add them as options to the default > data sources as well? That would become a mess. > Thus I'm leaning towards a simple one choice pool by default, if > you want to get fancy, use the advanced factories, that will take > a DataSource parameter instead. > > Well, that's more or less it. Long story short, if you were using > the old datastores with the parameter map mechanism (DataStoreFinder > or direct usage of the DataStoreFactory), nothing changes for you, > otherwise either do the right thing (use the parameter map) or > change your code to provide a DataSource. > > If you have any questions, I'm all ears. > 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 > ------------------------------------------------------------------------- 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
