Mike Engelhart wrote:
> Craig R. McClanahan wrote:
>
> > This is not the way I would have approached it. Instead, I would've hidden
> > any
> > waiting inside the getConnection() method itself. In fact, the connection
> > pool I
> > use (home grown) has two versions of the getConnection call -- one that keeps
> > waiting "forever" for a connection to be available (once the configured
> > maximum
> > number of connections have been created), and one that will return a timeout
> > exception after a specified number of milliseconds of waiting.
> Thanks Craig - that's a much cleaner approach. Works beautifully. I didn't
> realize (until you just pointed me in that direction) that wait() and
> notify() are inherited from Object. I thought for some reason I would have
> to implement at least Thread to get this to work.
>
> One question, are you just overloading the getConnection() methods by
> passing in a timeout value or using some other mechanism?
>
In my connection pool implementation, I overload it like this:
public Connection getConnection();
public Connection getConnection(long timeout) throws TimeoutException;
This way, I never have to worry about getting a null value back. It complicates
the code inside the connection pool, but makes life much easier on all the
callers.
>
> Mike
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
