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 14:54:42 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 dgraham@apache.org  2003-03-28 14:54 -------
>In session based Web applications, most connections only have one or


>two statements in use at any given time, hence you're correct in that


>MaxOpenStmts isn't very useful in working code.  You will run into a


>resource leak if for some reason you don't close the prepared stmts


>(with or without the caching).   




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




>By setting MaxOpenStmts to something


>low, you can quickly detect whether your application is leaking


>prepared stmts since the code will throw an NoSuchResource exception


>when you hit the limit.




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.  
Your code would deadlock before the pool threw the exception.




IMHO, this is better handled at the Connection level.




>


> >An alternative implementation of the statement pooling could be done


> >by the Connection rather than the DataSource.  Because a different


> >statement pool is created for each Connection, it might make sense to


> >put this behavior in the Connection class.


>


>Not an unreasonable thought, but PoolableConnectionFactory already had


>the interface to this (it just wasn't implemented in BasicDataSource)


>and it was trivial to add the new parameters to BasicDataSourceFactory.


>  It was certainly the smallest number of changes.


>


>


>mp


>

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