【正文】 } // Call the Action instance itself ActionForward forward = processActionPerform(request, response, action, form, mapping)。 } // Check for any role required to perform this action if (!processRoles(request, response, mapping)) { return。 + path + 39。 } public void setConfigFile(String string) { configFile = string。ve covered in this chapter.Table 199: OCI versus Thin driver timings (in milliseconds)MetricOCIThin1,000 inserts with automit3,7123,6751,000 inserts with manual mit2,6132,5941 insert with Statement10101,000 inserts with Statement2,8042,5831 insert with PreparedStatement1131131,000 inserts batched1,482367SELECT1010Predefined SELECT10101 insert with CallableStatement1131171,000 inserts with CallableStatement1,7231,752Totals12,59011,231As you can see from Table 199, the Thin driver clearly outperforms the OCI driver for every type of operation except executions of CallableStatement objects. On a Unix platform, my experience has been that the CallableStatement numbers are tilted even more in favor of the OCI driver. Nonetheless, you can feel pletely fortable using the Thin driver in almost any setting. The Thin driver has been welltuned by Oracle39。ve looked at automit, SQL92 parsing, prepared statements, and a predefined SELECT, let39。s a catch here. The OCI driver has a defect by which it does not support standard Java batching, so the numbers reported here were derived using Oracle39。s not until about 65 inserts that the PreparedStatement object outperforms the Statement object. 65 inserts! Clearly, the Statement object is more efficient under typical use when using the OCI driver.Figure 191The Thin DriverIf you examine Table 194 (which shows the same timings as for Table 193, but for the Thin driver) and Figure 192 (which shows the data incrementally), you39。s take a look at some numbers. Table 191 shows the average time, in milliseconds, needed to insert 1,000 rows into the TESTXXXPERF table using a Statement object. The timings represent the average from three runs of the program. Both drivers experience approximately a onesecond loss as overhead for mitting between each SQL statement. When you divide that one second by 1,000 inserts, you can see that turning off automit saves approximately seconds (1 millisecond) per SQL statement. While that39。ll only talk about them. Although the actual timing values change from system to system, their relative values, or ratios from one system to another, remain consistent. The timings used in this chapter were gathered using Windows 2000. Using objective data from these programs allows us to e to factual conclusions on which factors improve performance, rather than relying on hearsay.I39。s optimizer plans to execute your SQL statements. Armed with this knowledge, you may determine that additional indexes are needed, or that you require an alternative means of selecting the data you desire.On the other hand, when it es to using JDBC, you need to know ahead of time the relative strengths and weaknesses of using automit, SQL92 syntax, and a Statement versus a PreparedStatement versus a CallableStatement object. In this chapter, we39。ll examine the relative performance of various JDBC objects using example programs that report the amount of time it takes to acplish a given task. We39。m sure you39。s not interesting enough to write home about, it does demonstrate how automit can impact performance.Table 191: Automit timings (in milliseconds)AutomitOCIThinOn3,7123,675Off2,6132,594Clearly, it39。ll see that the Thin driver follows the same behavior as the OCI driver. However, since the Statement object starts out performing better than the PreparedStatement object, it takes about 125 inserts for the PreparedStatement to outperform Statement.Table 194: Thin driver timings (in milliseconds)InsertsStatementPreparedStatement1101131,0002,5831,739Figure 192When you consider typical SQL statement usage, even with the Thin driver, you39。s proprietary batching.Now, let39。s take a look at the performance of callable statements.CallableStatementsAs you may recall, CallableStatement objects are used to execute database stored procedures. I39。s JDBC development team to perform better than its OCI counterpart.原文二：Extending StrutsIntroductionI have seen lot of projects where the developers implemented a proprietary MVC framework, not because they wanted to do something fundamentally different from Struts, but because they were not aware of how to extend Struts. You can get total control by developing your own MVC framework, but it also means you have to mit a lot of resources to it, something that may not be possible in projects with tight schedules.Struts is not only a very powerful framework, but also very extensible. You can extend Struts in three ways.PlugIn: Create your own PlugIn class if you want to execute some business logic at application startup or shutdown. RequestProcessor: Create your own RequestProcessor if you want to execute some business logic at a particular point during the requestprocessing phase. For example, you might extend RequestProcessor to check that the user is logged in and he has one of the roles to execute a particular action before executing every request. ActionServlet: You can extend the ActionServlet class if you want to execute your business logic at either application startup or shutdown, or during request processing. But you should use it only in cases where neither PlugIn nor RequestProcessor is able to fulfill your requirement. In this article, we will use a sample Struts application to demonstrate how to extend Struts using each of these three approaches. Downloadable sample code for each is available below in the Resources secti