speaking out of ignorance here, so please be patient I will be totally fine with this when I can set up datastores to use DataSource through JNDI on the major commercial J2EE servers.
Would love to contribute instructions on how to do that at least for the ones there are linux trials (websphere, sun's, what else?) Andrea, a quick pointer to instructions on how to set up through JNDI? (excuse my lazyness, lots of stuff going on..) cheers! Gabriel On Monday 18 June 2007 21:14:38 Chris Holmes wrote: > 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+upgra > >de > > > > 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! ------------------------------------------------------------------------- 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
