The geometryless datastore already uses driver name and url parameter
strategy for similar reasons. This data store can use any jdbc driver,
and there wasnt enough predictability in the format to assume anything -
particularly using things like Oracle OCI.
Also, it turned out to be extremely convenient to get the jdbc url
working first, in something like DBvisualiser rather than try to debug
parameter by parameter, when geoserver has a tendency to hide every
potentially useful config error message.
I ended up creating wrappers for pooled connection data so that I could
use a setURL method, which unfortunately wasnt supported in the standard
interface, but am unhappy with this, and was hoping the pooled
connection stuff would show a better way. This is particularly bad in
terms of potentially requiring dependencies on third party drivers in
the build. Ended up commenting the wrappers out...
Anyway, I'm all for this, and will update the geometryless datastore
when its ready to roll, its addressing one of the main blockers for me
to get it supported.
Cheers
Rob A
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard
-------------------------------------------------------------------------
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
