commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: DBCP PoolingDataSource
Date Wed, 16 Jan 2002 18:18:37 GMT


On Wed, 16 Jan 2002, Juozas Baliuka wrote:

> Date: Wed, 16 Jan 2002 18:34:14 +0100
> From: Juozas Baliuka <baliuka@mwm.lt>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message