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?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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