One other thought is to have the driver class name and url's filled out
as defaults in the factory. In an app like uDig they can just be part
of the 'advanced' tab. For GeoServer a user would get default values,
and they wouldn't know what they do, so they'd just leave them in. That
might not be so bad, and could be better than making them pick one of
two datastores. And we could perhaps figure out some sort of 'advanced'
tab when we get a new ui.
C
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
!DSPAM:4005,4673e79c259478362916074!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
email;internet:[EMAIL PROTECTED]
title:Managing Director, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
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
