Srini wrote:
>
> Yes i too tried the same connection pooling and found for each
> and every time it has been increased to one.
Looks like when there's a problem with a connection, the pool makes a
new one to replace the broken connection, but it never *removes* the
broken connection from the list. This causes the list to grow by one
each time a connection breaks. You only stumble on this bug if you
have connections dying all over the place, which you must have.
The workaround would be to remove() the dead connection before putting
the new one in the hashtable. You have to be careful with this because
we're changing the hashtable while we're iterating over an enumeration
of hashtable elements, but since the remove() will happen right before
the return, we're OK.
Does that seem to explain everything?
If you find that the getConnection() code in the catch block isn't being
executed each time, then it seems the only other explanation is that the
hashCode() on the connection is somehow broken because the put() using
the same connection as the key should replace the existing value.
Another workaround is to use a connection pool intended for production
use. This one was meant to demonstrate how a pool could be written.
See http://www.javaexchange.com for a widely used (free, I think) pool.
-jh-
--
Jason Hunter
[EMAIL PROTECTED]
Book: http://www.servlets.com/book
2.0 to 2.1: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
2.1 to 2.2: http://www.javaworld.com/jw-10-1999/jw-10-servletapi.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
