Another point w.r.t. getConnection(user, password). Sometimes it's desireable not to put the ID and password in a place where it ends up going into the regular JDBC/JNDI URL. Possibly for security purposes; more likely because you really need different credentials in different scenarios. So you specify your URL w/o any credentials and then you use getConnection(user,password) to supply the credentials at runtime.
In pools I've written in the past (C++ - sorry ;), I've made the lookup on "URL + user + password" (really the equivalent of URL, but you get the point). So you can still pool the connections and reuse them when getConnection(user, password) is called. The pool just has to have a little more smarts about how a reusable connection is identified. FWIW... Donnie > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 16, 2002 1:19 PM > To: Jakarta Commons Developers List > Subject: RE: DBCP PoolingDataSource > > > > > On Wed, 16 Jan 2002, Juozas Baliuka wrote: > > > Date: Wed, 16 Jan 2002 18:34:14 +0100 > > From: Juozas Baliuka <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List > <[EMAIL PROTECTED]> > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > Subject: RE: DBCP PoolingDataSource > > > > Hi, > > I think there is no need to implement method > getConnection(user,password) > > for DataSource, > > In most cases DataSource configured in JNDI and If your > Datasorce is kid of > > ConnectionPoolDatasource, it is not very good to relogin users( it means > > reopen connection). > > If you always have single user for DB authentication, there > is no need > > to know this user for application. > > It can be useful if application uses DB authentication, I > don't know is it > > good or not, I have never saw > > application using DB authentication and Datasource. > > > > Connection getConnection(String user,String password){ > > > > return getConnection(); > > > > } > > May be it is bad implementation, but I always use it this way. > > > > IMHO, this would be dangerous -- and the current approach of throwing > UnsupportedOperationException is better if the operation is, in fact, not > supported. > > Different database usernames are configured with different access > permissions for various portions of the database. Silently returning a > connection with different permissions than the ones you think you get is > going to lead to very hard-to-find bugs, plus the ability to potentially > modify things you should not be able to (if the default username/password > identifies a database user with more privileges versus the user you are > asking for). > > There are use cases where simultaneous connections on multiple usernames > would be useful. You can work around it (until this feature is > implemented) by creating a separate pool for each username/password > combination, but this doesn't allow the pool to share resources as well as > is possible when it's all one pool. > > Craig > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
