【正文】 ou can improve the performance of a SELECT statement by 50% if you predefine the Selecstatement by using Oracle39。re really going to do that many executions of a statement, or perhaps more than 50, you should consider batching. Batching is more efficient because it sends multiple SQL statements to the server at one time. Although JDBC defines batching capability for Statement objects, Oracle supports batching only when PreparedStatement objects are used. This makes some sense. A SQL statement in a PreparedStatement object is parsed once and can be reused many times. This naturally lends itself to batching. The OCI DriverTable 195 lists Statement and batched PreparedStatement timings, in milliseconds, for 1 insert and for 1,000 inserts. At the low end, one insert, you take a small performance hit for supporting batching. At the high end, 1,000 inserts, you39。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. When it es 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 application1 or 2 here, maybe 1020 (rarely more) per transactionyou realize that a Statement object will perform them in less time than a PreparedStatement object. In the next two sections, we39。alter table TestXXXPerfadd constraint TestXXXPerf_Pkprimary key ( id )using indextablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 )。ll also examine the performance of the OCI versus the Thin driver in each situation to see if, as Oracle39。原文一：Java Programming with Oracle JDBC：PerformancePerformance is usually considered an issue at the end of a development cycle when it should really be considered from the , a task called performance tuning is done after the coding is plete, and the end user of a program plains about how long it takes the program to plete a particular net result of waiting until the end of the development cycle to consider performance includes the expense of the additional time required to recode a program to improve its 39。ll start a series of parisons of the Statement object versus the PreparedStatement object versus the CallableStatement object. At the same time we39。s get started with a look at the testing framework used in this chapter.A Testing FrameworkFor the most part, the test programs in this chapter report the timings for inserting data into a table. I picked an INSERT statement because it eliminates the performance gain of the database block buffers that may skew timings for an UPDATE, DELETE, or SELECT .The test table used in the example programs in this chapter is a simple relational table. I wanted it to have a NUMBER, a small VARCHAR2, a large VARCHAR2, and a DATE column. Table TESTXXXPERF is defined as:create table TestXXXPerf (id number,code varchar2(30),descr varchar2(80),insert_user varchar2(30),insert_date date )tablespace users pctfree 20storage( initial 1 M next 1 M pctincrease 0 )。s move on to something that has some potential for providing a substantial performance improvement.Statement Versus PreparedStatementThere39。re going to execute a given SQL statement a large number of times, it makes sense from a performance standpoint to use a PreparedStatement object. But if you39。ve finished looking at improving the performance of inserts, updates, and deletes. Now let39。s simply not true. Given a simple SQL statement, and a stored procedure call that acplishes the same task, the simple SQL statement will always execute faster. Why? Because with the stored procedure, you not only have the time needed to execute the SQL statement but also the time needed to deal with the overhead of the procedure call itself. Table 198 lists the relative time, in milliseconds, needed to call the stored procedure TESTXXXPERF$.SETTESTXXXPERF（）. This stored procedure inserts one row into the table TESTXXXPERF. Timings are provided for both the OCI and Thin drivers. Notice that both drivers are slower when inserting a row this way than when using either a statement or a batched prepared statement (refer to Tables 193 through 196). Common sense will tell you why. The SETTESTXXXPERF（）procedure inserts a row into the database. It does exactly the same thing that the other JDBC objects did but with the added overhead of a round trip for executing the remote procedure call.Table 198: Stored procedure call timings (in milliseconds)InsertsOCIThin11131171,0001,7231,752Stored procedures do have their uses. If you have a plex task that requires several SQL statements to plete, and you encapsulate those SQL statements into a stored procedure that you then call only once, you39。 } //This method will be called at application startup time public void init(ActionServlet actionServlet, ModuleConfig config) throws ServletException { (Entering ())。 if (path == null) { return。 processNoCache(request, response)。 } // Process a forward or include specified by this mapping if (!processForward(request, response, mapping)) { return。t want that to happen, then you can set the locale property to false in ControllerConfig by adding these lines to your file: controller setproperty property=locale value=false//controllerprocessContent():Sets contentType for by calling (). This method first tries to get the contentType as configured in . It will use text/html by default. To override that, use the following: controlle