What advantage is there to using prepared statements if I am using connection pooling or closing the connection frequently to avoid resource/connection/cursor limitations?
The ability to choose the ‘best’ efficiency ( or evaluate tradeoffs, if you prefer, ) is, at times, the most important piece of a mature developer’s skillset. This is YAA ( Yet Another Area, ) where that maxim applies. Apparently there is an effort to allow prepared statements to work ‘better’ with connection pools in JDBC 3.0, but for now, one loses most of the original benefit of prepared statements when the connection is closed. A prepared statement obviously fits best when a statement differing only in variable criteria is executed over and over without closing the statement. However, depending on the DB engine, the SQL may be cached and reused even for a different prepared statement and most of the work is done by the DB engine rather than the driver. In addition, prepared statements deal with data conversions that can be error prone in straight ahead, built on the fly SQL; handling quotes and dates in a manner transparent to the developer, for example.
Related Questions
- What advantage is there to using prepared statements if I am using connection pooling or closing the connection frequently to avoid resource/connection/cursor limitations?
- Are national delegations expected to make an opening and/or closing statements in plenary at VI CEA. How much time would be allotted to national for this?
- Are there any connection or capacity limitations with the premium AddOns for the Perpetual Edition?
