Well, depends how we look at it. The current implementation is that the JDBC layer on the client replaces the ? placeholders in the statement that is submitted to the server, with the string representation of the objects that are in the parameter list. Each time executeQuery() is called, this replacement takes place and a normal statement is generated and sent to the server.
Campbell was apparently talking about an implementation that does not change this scheme as far as talking to the server is concerned. The only difference is the client sends the original statement to the server with the ? placeholders intact. Then each time you use executeQuery(), this is translated to a CALL statement. We can do it differently of course. Say send the original statement the same way, but send the parameter list as serialised binary objects packaged in a way that the server understands and acts upon. When the standalone mode is used, there is of course no need to serialise or deserialise. Three years ago I implemented a client-server system in RMI and this sort of thing was very,very simple to implement and test. Alternatively, if we don't want to change the whole current communication protocol, we can just pack and unpack the stuff with a special header. Fairly simple. The more important bit is reengineering the core to support this. After the changes Bob and I made to the code, it is not too difficult to implement insert, update and delete prepared statements. Select is a bit more difficult. In all cases, prepared statement that involve expressions that have to be evaluated at the time of execution would have to be parsed again and again. Fred ----- Original Message ----- From: "Karl Meissner" <[EMAIL PROTECTED]> To: "Campbell Boucher-Burnet" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: 08 April 2002 14:20 Subject: Re: [Hsqldb-developers] On The Subject Of Prepared And Callable Statements: I think we may be talking past each other. I believe you are envisioning a usage model when all the SQL is executed from a script. That is an important model and you may be correct about that usage model. Another way to use HSQL is from within a java application or JSP. In that case you can connect directly to the db engine and take advantage of JDBC. I think in that case prepared statements have a *lot* of value. There is no need to use "CALL" then. > First, a CALL must be made to prepare the statement, > saving it on the server under a handle (say CALL > prepare(sql) returns int), then another CALL must be > made to execute the prepared statement (say CALL > execute(int) returns Result). As such, the call to > execute the prepared statement must itself be > parsed, Check out the API for java.sql.PreparedStatement http://java.sun.com/j2se/1.4/docs/api/index.html The parser is called *once*, when the PreparedStatement is first constructed in the Connection.preparedStatement After that simply set the parameters and call executeQuery(). Implemented correctly, PreparedStatement.executeQuery() should be list of atomic operation on the db. Each operation is an object which supports an exec( ) function. Just go over the list and excecute each operation. This would be ideal for a threaded web server app that must connect to the db and execute a small set of queries with a few parameters over and over. It greatly reduces the overhead of parsing to almost nothing. > performing a CALL uses Java reflection to match the > procedure name with a java.lang.reflect.Method, I dont see the need for using Reflection at all if we use PreparedStatement. >As you can see, the overhead currently associated >with parsing and executing a "CALL" statement ruins >any benefit obtained by accessing a prepared >(precompiled) select statement, even a moderately >complex one. >~ 60% of statement processing time for the standard >test script is spent in the parsing phase, Ouch! that whole thing can be optimized away. At least when you in a JSP or Java application with a simple set of queries. >with ~20% in actual update, >and another ~20% spent in logging We should have more fine grain control of logging. >most direct way to improve the over-all performance >of the hsql database engine for short-running >statements is to really focus mostly on speeding up >and making the parser more efficient, if possible. Of course this is good goal. ===== Karl Meissner ........................................................... : Meissner Software Development, LLC : : "Software development and project management services." : : http://meissner.v0.net/resume.htm : ........................................................... __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
