Re: [Geotools-devel] Everybody out of the pool please

[Jody G. <jga...@re...>]

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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>