Community
Participate
Working Groups
Advantages: - Possible higher performance with many executes - Automatic data type conversion - BLOB, CLOB, ... Disadvantages: - Runtime overhead - Additional state to be managed when cached - Caching expensive since associated with a dedicated connection - Unclear if connection/datasource implementation already uses caching
Reversioned due to graduation
Stefan, is this an enhancement of the DBStore you'd like to work on? See also the relation to bug #249681 ...
http://www.javaworld.com/javaworld/jw-01-2002/jw-0125-overpower.html http://www.theserverside.com/tt/articles/article.tss?l=Prepared-Statments http://en.wikipedia.org/wiki/Sql_injection http://www.onjava.com/lpt/a/1480 exerpt from http://www.oreilly.com/catalog/joraj...pter/ch19.html "Statement Versus PreparedStatement There's a popular belief that using a PreparedStatement object is faster than using a Statement object. After all, a prepared statement has to verify its metadata against the database only once, while a statement has to do it every time. So how could it be any other way? Well, the truth of the matter is that it takes about 65 iterations of a prepared statement before its total time for execution catches up with a statement. This has performance implications for your application, and exploring these issues is what this section is all about. When it comes to which SQL statement object performs better under typical use, a Statement or a PreparedStatement, the truth is that the Statement object yields the best performance. When you consider how SQL statements are typically used in an application--1 or 2 here, maybe 10-20 (rarely more) per transaction--you realize that a Statement object will perform them in less time than a PreparedStatement object."
Created attachment 116930 [details] Patch v1 Patch implementing JDBC delegate interface in patch-v1 attached to Bug 253664.
Patch v1 needs remerge with HEAD ;-(
Created attachment 117547 [details] New patch based on current HEAD
Committed to HEAD. Stefan, should we change the default in the cdo-server.xml file to "preparedStatement"?
> Stefan, should we change the default in the cdo-server.xml file to > "preparedStatement"? mhhh ... actually that's a good question.(In reply to comment #7) For the long term: yes, for the short term: I don't know. Arguments: + all test cases that passed before also pass with PreparedStatement + preparedStatement fixes Bugs 244290 (Quote escaping) and 249681 (storing date) (these issues still remain with the non-prepared case - if someone wants them fixed, please REOPEN the respective bugs!) - preparedStatements have not been thoroughly performance-measured with different databases and JDBC drivers. I am also still not sure about JDBC-level preparedStatement caching. So while the two bugs above are not an issue anymore with preparedStatements, I can not as of now guarantee that preparedStatements may be even slower than non-prepared in some cases. So maybe set is as default, but document the possible issues which have not yet been evaluated.
Because of bug #255322 I'll postpone the change of the default...
Fix available in CDO 2.0.0M3
Generally available.
