On Wed, Nov 14, 2012 at 6:02 AM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
> Hi all,
>
> I am experimenting with a way to supply my own customized DataSource
> wrapper to a jdbc datastore. Basically my use case is playing with a
> connection proxy library like log4jdbc to log some more extended
> information about connections, monitor possible connection leaks, etc...
>
> Now, I know that I can pass in a direct DataSource implementation into a
> datastore via the JDBCDAtaStoreFactory.DATASOURCE parameter but that isn't
> ideal for my case as I want to use this in situations like GeoServer where
> data stores are created from serialized connection parameters, and I want
> something that will be or less transparent to that process. I looked at the
> ConnectionLifecycleListener stuff, which while very nice and gets me part
> of what i want, doesn't do it all since i actually need to wrap
> connections.
>
> So... looking around I actually see something that fits the bill in the
> shape of DataSourceFactorySpi. As far as i can tell though this api isn't
> really used at all by the jdbc datastore subsystem, well for creation of a
> data source at least. The only usage from jdbc itself seems to be the
> UnWrapper interface which is used by oracle to access the native oracle
> connection. The api does seem to be used in coverage land by imagemosaic
> for creating a jdbc datasource for the tile index (or so i assume).
>
> Basically what I was thinking was something like adding
> a DataSourceFactorySpi member to JDBCDataStoreFactory, the default value of
> which being a factory that creates a dbcp data source like is done today.
> By making the member settable it should be easy enough to specify your own
> custom DataSource. It would look something like:
>
> Map connectionParams = ...
> JDBCDAtaStoreFactory factory = getFactoryFromParams(connectionParams);
> factory.setDataSourceFactory(new MyCustomDataSourceFactory());
>
>
> Long story short I can think of two approaches (and alternatives very
> welcome).
>
> 1. Try to utilize DataStoreFactorySpi
> 2. Roll a more specific interface for this case
>
> I spent some time exploring option (1), but there are a couple of
> obstacles with it. The main one is that DataStoreFactorySpi implementations
> use different parameters than JDBCDataStoreFactory does. The parameters are
> similar, but different enough. For instance the DBCPDataSourceFactory uses
> "username"/"password" rather than "user"/"passwd".
> The DBCPDataSourceFactory also misses a number of parameters such as
> prepared statement pooling options, connection timeout, validation, etc...
>
> I couldn't come up with a great solution for this. I experimented with a
> sub interface named DataStoreFactorySpi2 that added the following method:
>
> Map convertDataStoreParameters(Map params, JDBCDataStoreFactory
> dataStoreFactory, SQLDialect dialect)
>
>
> Which basically transformed the dataStore factory parameters to the ones
> needed by the data source. This kind of worked but was pretty messy as much
> of the data source configuration logic is dependent on the dialect itself,
> whether its prepared statement or not, etc... This option also requires
> more or less duplicating all the connection parameters from the data store,
> etc...
>
> So... (1) is probably doable, but far from trivial and could get messy.
>
>
> Approach (2) would really just be the simplest thing I can think of.
> Basically the interface would be the
> JDBCDataStoreFactory.createDataStore(Map, SQLDialect) method factored out
> into an interace:
>
> interface JDBCDataSource[Factory|Builder|Creator|WWW] {
>
> DataSource createDataSource(Map params, SQLDialect dialect);
>
> }
>
>
> With the default implementation doing exactly what the existing method
> does today, and that is return a BasicDataSource, wrapped in the manageable
> DBCPDataSource wrapper. An alternative implementation would be used by
> the JDBCJNDIDataStoreFactory.
>
>
> Any thoughts or suggestions?
>
The DataSourceFactorySpi was though to give the possibility of creating new
connection pools,
but the initial attempt of using C3P0 did not provide the expected results,
so it was left
there to languish.
I'd say, please revive it. Make the necessary changes, as you said it's not
used much anyways,
so there is little harm in changing some param names.
It's going to be less confusing than rolling a sibling interface
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
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
-------------------------------------------------------
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
