Re: GenericDataSource Enhancement

2001-01-08 Thread Johan Compagner
> Except that the javax.sql.DataSource API still includes this method signature, so we >need to do something. I guess > it would probably be better to return a "not implemented" exception of some sort, >then just return a "regular" > connection like it does now. Yes or just a normal connection

Re: GenericDataSource Enhancement

2001-01-07 Thread Craig R. McClanahan
Johan Compagner wrote: > > I suppose besides adding datasources with different logins, we could > > also add entirely different DBMS's?, on entirely different servers? > > Yes that is what the current solution already offers. So the getConnection(String >user, String pasword) > doesn't have to b

Re: GenericDataSource Enhancement

2001-01-07 Thread Johan Compagner
> I suppose besides adding datasources with different logins, we could > also add entirely different DBMS's?, on entirely different servers? Yes that is what the current solution already offers. So the getConnection(String user, String pasword) doesn't have to be implemented, Because if you real

Re: GenericDataSource Enhancement

2001-01-07 Thread Ted Husted
On 1/6/2001 at 12:26 PM Craig R. McClanahan wrote: >Personally, I've never found the need for the multiple username/password combinations feature. I either let my application manage database access rights, or (on a database like Oracle that supports them) use database roles to restrict DB privile

Re: GenericDataSource Enhancement

2001-01-07 Thread Ted Husted
On 1/6/2001 at 12:26 PM Craig R. McClanahan wrote: > I would imagine you'd need to maintain a pool of connections for each username/password combination that was requested. To avoid filling the entire pool with one-off requests, there would probably also need to be some sort of timeout mechanism

Re: GenericDataSource Enhancement

2001-01-06 Thread Craig R. McClanahan
Johan Compagner wrote: > > It certainly could, along with other stuff like implementing the > > getConnection(username, password) call correctly. > > How should it work? > > You can't change a current connections username and password (correct me if i am >wrong) > So you have to build up a new c

Re: GenericDataSource Enhancement

2001-01-06 Thread Johan Compagner
> It certainly could, along with other stuff like implementing the > getConnection(username, password) call correctly. How should it work? You can't change a current connections username and password (correct me if i am wrong) So you have to build up a new connection with the supplied username a

Re: GenericDataSource Enhancement

2001-01-04 Thread David Winterfeldt
It can wait until after 1.0 is released. If it could get fixed in the next couple of weeks, that would be good. David Winterfeldt --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > David Winterfeldt wrote: > > > I don't see GenericDataSource checking to see if a > > connection is dead/clos

RE: GenericDataSource Enhancement

2001-01-04 Thread McCay, Larry
EMAIL PROTECTED] Subject: Re: GenericDataSource Enhancement David Winterfeldt wrote: > I don't see GenericDataSource checking to see if a > connection is dead/closed before it returns it from > the pool. I think my ISP shuts down the database at > night for backups and it kil

Re: GenericDataSource Enhancement

2001-01-04 Thread Craig R. McClanahan
David Winterfeldt wrote: > I don't see GenericDataSource checking to see if a > connection is dead/closed before it returns it from > the pool. I think my ISP shuts down the database at > night for backups and it kills the connection pool. > > Could checking to see if the connection is live > (r