[jira] Closed: (DBCP-301) maxOpenPreparedStatements needs a better default or at least better documentation.

["Phil Steitz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DBCP-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Phil Steitz closed DBCP-301.
----------------------------


> maxOpenPreparedStatements needs a better default or at least better documentation.
> ----------------------------------------------------------------------------------
>
>                 Key: DBCP-301
>                 URL: https://issues.apache.org/jira/browse/DBCP-301
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.2.2
>         Environment: Tomcat 6.0.20, Sun Java 1.6.0_16
>            Reporter: Bill Davidson
>             Fix For: 1.3
>
>
> If you set poolPreparedStatements="true", it is important to set the maxOpenPreparedStatements to something reasonable.  The default of unlimited is very likely to cause many applications to run out of cursors, since pooled PreparedStatement objects are not actually closed, which means they keep cursors open.  I ran out of cursors because of this using Oracle.
> I realize that setting the right default is problematic, and the best choice almost certainly varies with which DBMS is being used, how much memory it has available and the nature of the application.  Perhaps better warnings in the documentation would make more sense.
> The current configuration documentation for these options contains only this warning:
> "NOTE - Make sure your connection has some resources left for the other statements."
> That really doesn't make it clear that poolPreparedStatements is going to eat up all of your database cursors after a while if you keep connections open for very long (as you might if you have a very active system).
> It would be nice to have some sort of warning there letting people know that using poolPreparedStatements but not setting an appropriate maxOpenPreparedStatements has a high probability of causing problems on busy systems.  Maybe something like this:
> NOTE - When setting poolPreparedStatements="true" it is highly recommended that you also set maxOpenPreparedStatements to a value appropriate to your DBMS and application.  Pooled PreparedStatement objects are not closed, and so can keep to many database cursors open on busy systems which can consume all of your cursor resources.  The optimal value of maxOpenPreparedStatements  will depend upon your DBMS, the application, and your hardware resources but it must be set to something less than the maximum number of open cursors allowed on a Connection by your DBMS.
> I'm sure that it could probably be worded better.  I'm just trying to get the idea across.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.