commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18012] - BasicDataSource doesn't include PreparedStmt Pooling
Date Fri, 28 Mar 2003 21:35:37 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18012>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18012

BasicDataSource doesn't include PreparedStmt Pooling





------- Additional Comments From mike@mpsharp.com  2003-03-28 21:35 -------

>Aren't PreparedStatements "closed" whenever the Connection that generated them 
>is closed?.  If so, then open statements are not the problem, open connections 
>are.

Since the connections are cached as well, they aren't actually ever closed, futhermore, hence
in some JDBC implementations I've seen resource leaks by not explicitly closing every result
and prepared stmt.

>So the code throws the exception when a client requests a PreparedStatement >that is
already open?  How many copies of each PS are stored in the pool?  It >seems like the client
should block on that request until the statement is >available. 

No, you never want to do this.  It would be extremely unusual (and painful) to have two threads
using the same connection.  If you start blocking for a statement, what thread is going to
release it?  PS's are a per connection animal, so there is only one per pool.

>IMHO, this is better handled at the Connection level.

Possibly.  I was simply following rwaldhoff's lead and I didn't see a compelling reason to
rewrite PoolableConnectionFactory.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message