commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James House <ja...@interobjective.com>
Subject RE: pools - borrowing from pools
Date Fri, 25 Jan 2002 17:39:26 GMT

I would vote for checked exceptions also.

BTW: Did you see my posts from a week+ ago regarding DBCP?

I strongly believe that PooledDataSource.getConnection() should throw a 
SQLException if the pool is exhausted or whatever.  This is what JDBC code 
expected getConnection() to throw if the connection fails, and an exhausted 
pool is functionally the same as a failed exception (in my opinion).

Also, in another mail (the same day) I suggested a fix to the validation 
test for borrow/return of connections.

I've also found a few other similar things - like the fact that the 
Statements (and Prepared and Callable statements) created from a pooled 
connection should return the pooled connection that made them from their 
getConnection() method, rather than return the underlying physical 
connection... this seems dangerous - what if someone called close() on it?

James


At 1/22/2002 08:02 AM -0600, you wrote:
> > I'm using the common-pools and was wondering how
> > most people handle failure to borrow from a pool.
> > Ie ObjectPool.borrowObject() doesn't declare any
> > checked Exception, so how are clients meant to be
> > notified that a pooled Object cannot be supplied?
>
>I've been returning null or throwing java.util.NoSuchElementException
>depending upon the context.  That's this:
>
> > 1) Create a class of unchecked Exception
> > which is thrown when the pool cannot
> > supply an object
>
>(skipping the "create" part), but certainly not this:
>
> > 2) Have the client catch all
> > RuntimeExceptions and assume
> > that is what this failure
> > represents
>
>NoSuchElement seems appropriate, although a small tree of (checked) pool
>exceptions might be better, and as Heiko noted in another thread (Re: Why
>are there no Exceptions?) there are other lifecycle events that may be
>considered exceptional.  I'd be open to patching this up.


--
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