6 Optimizing J2EE Applications In OC4J

6.3.1 Setting the JVM Heap Size for OC4J Processes

If you have sufficient memory available on your system and your application is memory intensive, you can improve your application performance by increasing the JVM heap size from the default value. While the amount of heap size required varies based on the application and on the amount of memory available, for most OC4J server applications, a heap size of at least 256 Megabytes is advised. If you have sufficient memory, using a heap size of 512 Megabytes or larger is preferable.

To change the size of the heap allocated to the OC4J processes in an OC4J instance, use the procedures outlined in "Using Application Server Control Console to Change JVM Command Line Options", and specify the following Java options:

-Xmssizem -Xmxsizem

Where size is the desired Java heap size in megabytes.

If you know that your application will consistently require a larger amount of heap, you can improve performance by setting the minimum heap size equal to the maximum heap size, by setting the JVM -Xms size to be the same as the -Xmx size.

For example, to specify a heap size of 512 megabytes, specify the following:

-Xms512m -Xmx512m

You should set your maximum Java heap size so that the total memory consumed by all of the JVMs running on the system does not exceed the memory capacity of your system. If you select a value for the Java heap size that is too large for your hardware configuration, one or more of the OC4J processes within the OC4J instance may not start, and Oracle Enterprise Manager 10g Application Server Control Console reports an error. Review the log files for the OC4J instance in the directory $ORACLE_HOME/opmn/logs, to find the error report:

Could not reserve enough space for object heap
Error occurred during initialization of VM

If you select a value for the JVM heap size that is too small, none of the OC4J processes will be able to start, and, after a timeout while attempting to make the change, Application Server Control Console reports an error, "An error occurred while restarting..." In this case, if you review the log files for the OC4J instance in the directory $ORACLE_HOME/opmn/logs, you may find errors similar to the following:

java.lang.OutOfMemoryError

If the system runs out of memory, the OC4J process will shut down. This will happen if references to the objects are not released. For example, if objects are stored in a hash table or vector and never again removed.

It is of course possible that your process actually needs to use a lot of memory. In this case, the maximum heap size for the process should be increased to avoid frequent garbage collection.

To maximize performance, set the maximum heap size to accommodate application requirements. To determine how much Java heap you need, use the JVM metrics freeMemory and totalMemory. Subtracting the free memory from total memory gives the amount of heap that was consumed. To determine how much Java heap you need in a non-production environment, you can include calls in your program to the Runtime.getRuntime().totalMemory() and Runtime.getRuntime().freeMemory methods in the java.lang package (including these calls in a production environment could have a negative performance impact).

6.3.2 Setting the JVM Server Option for OC4J Processes

Oracle Application Server 10g uses the -server option by default on UNIX systems (this is a change from previous Oracle9iAS releases). On UNIX systems, Java runs in one of two modes set with the options: -client and -server. If you need to change this option, use the procedures outlined in "Using Application Server Control Console to Change JVM Command Line Options", and specify the -client Java option.

Oracle Application Server 10g uses the 1.4.2 version of the Java virtual machine (JVM). This JVM version includes an improved JIT compiler from previous JVM releases. Many long-running applications will perform better with the improved JIT. However, due to the increased quality of compilation, applications may experience slower program startup times or occasional pauses in other parts of a program (as compared with older versions of the JVM). In a multi-processor system, the compilation thread runs concurrently with OC4J startup, reducing the impact on startup time.

On UNIX systems, using the –server option also changes the default heap allocation. For a given heap size, larger allocations are made to the Eden and Survivor generations at the expense of the Old generation. The Permanent generation is not affected. The memory footprint of the heap is not directly affected. See the following site for more details on heap sizes, generation names, and garbage collection,

http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/

6.3.3 Setting the JVM AggressiveHeap Option for OC4J Processes

In the 1.4.2 version of the Java virtual machine (JVM), the -XX:+AggressiveHeap option was optimized for long-running, memory allocation-intensive applications. Many applications will exhibit dramatically improved performance and scalability if the -XX:+AggressiveHeap option is specified. To set this option, use the procedures outlined in "Using Application Server Control Console to Change JVM Command Line Options".

See the following site for more details on using the -XX:+AggressiveHeap option,

http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html#6

6.3.4 Setting the JVM Stack Size Option for OC4J Processes

Depending on the particular J2EE application, changing the setting of the command line option -Xssn for the JVM running OC4J may improve performance. To set this option, use the procedures outlined in "Using Application Server Control Console to Change JVM Command Line Options", and specify the -Xssn Java option.

This option sets the maximum stack size for C code in a thread to the specified value n. Every thread that is spawned during the execution of the program passed to java has n as its C code stack size. The default C code stack size is 512 kilobytes (-Xss512k). A value of 64 kilobytes is the smallest amount of C code stack space allowed per thread.

Oracle recommends that you try the following value to improve the performance of your J2EE applications:

-Xss128k

6.3.5 Setting the JVM Permanent Generation Option for OC4J Processes

The MaxPermSize option defines the size for the permanent generation in the JDK. Since the default value is 64M (Megabytes) in JDK 1.4.x, generally you do not need to change this value, which is used to hold reflective objects of the VM such as class objects and method objects. However, if your applications dynamically generate and load many classes that require a large permanent generation size, you may see outOfMemory errors from the JDK even if you have plenty of free memory in the heap (we found this occurs in some JSP implementations). If this occurs, you can change the permanent generation size by setting the -XX:MaxPermSize option, as follows:

-XX:MaxPermSize=sizem

Where size is the desired MaxPermSize value.

6.3.6 Setting the OC4J DMS Sensors Option

You can disable the collection of most OC4J built-in performance metrics by setting a property for the JVM running OC4J. The default value for the property oracle.dms.sensors is normal, which enables the collection of built-in performance metrics. You can disable OC4J built-in performance metrics collection by setting the oracle.dms.sensors property to the value none. For most J2EE applications, using the default value, normal, should have minimal impact on performance.

Table 6-2 lists the supported oracle.dms.sensors property values.

Some Oracle Application Server components that run in OC4J do not use the oracle.dms.sensors property to control their metrics. For example, the Portal Servlet web.xml specified configuration parameter dmsLogging controls metric collection for the Portal PPE.

The JDBC drivers also do not use the oracle.dms.sensors property to control certain JDBC metrics. To enable the collection of JDBC statement metrics, use the properties, oracle.jdbc.DMSStatementCachingMetrics and oracle.jdbc.DMSStatementMetrics.

6.3.7 Setting the OC4J JDBC DMS Statement Metrics Option

To improve performance, by default OC4J does not collect JDBC statement metrics. The properties, oracle.jdbc.DMSStatementCachingMetrics and oracle.jdbc.DMSStatementMetrics are by default, set to false. When these properties are false, performance is improved since OC4J does not collect expensive JDBC statement level metrics.

Setting these properties to true may have a negative impact on performance. You should only set these properties to true when you need to collect JDBC statement metrics.

When oracle.jdbc.DMSStatementCachingMetrics property is set to true and JDBC statement caching is enabled, the JDBC statement metrics are available.

When JDBC statement caching is disabled, make the JDBC statement metrics available by setting the property oracle.jdbc.DMSStatementMetrics to true.

6.3.8 Setting the OC4J Dedicated RMI Context Option

Setting the dedicated RMI context property to false, using the command line option -Ddedicated.rmicontext= false, in certain cases may improve performance for OC4J.

6.3.9 Setting the OC4J EJB Wrapper Class Compilation Mode

When you deploy an application containing EJB JAR files, OC4J automatically generates a wrapper class for each EJB that implements the various component interfaces packaged with the EJB application. OC4J then invokes the Java compiler to compile these generated EJB wrapper classes. OC4J supports two modes for compiling EJB wrapper classes: Batch mode and non-batch mode.

Batch mode is the default compilation mode for OC4J. In general, batch mode provides faster time to deployment when deploying large EJB-heavy applications. However, batch mode also requires a greater heap memory allocation than non-batch mode deployment. In batch mode, OC4J makes a single call to the Java compiler to compile all of the Java wrapper code for all of the EJBs within the EAR being deployed.

You can specify non-batch mode if you find that OC4J throws java.lang.OutOfMemory exceptions while compiling in batch mode. If you encounter this exception, you may want to try selecting the non-batch mode, as it requires less memory allocation. However, using this mode can slow the deployment.

In non-batch mode, OC4J makes multiple calls to the compiler, one for each EJB JAR file within the EAR being deployed.

To deploy in non-batch mode, set the ejbdeploy.batch system property to false at OC4J startup using the command line option, -Dejbdeploy.batch=false.

6.3.10 Using Application Server Control Console to Change JVM Command Line Options

To change the command-line options for an OC4J instance, perform these steps:

1. Under the System Components table click and open the page for the OC4J instance on the Application Server Home page.

2. Click the Administration link on OC4J instance page.

3. Click Server Properties in the Instance Properties area on the Administration page.

4. Set Java Options in the Command Line Options area on the Server Properties page.

   For example, enter the following in the Java Options field to set the JVM heap size to 512 Megabytes:

   -Xmx512m
   
   

5. Click Apply to apply the changes.

   Click Yes to restart the OC4J instance to restart the OC4J instance.

Figure 6-1 shows the Server Properties page with Java Options.

Figure 6-1 Application Server Control Console Java Heap Size Multiple VM Configuration Page

Description of "Figure 6-1 Application Server Control Console Java Heap Size Multiple VM Configuration Page"

6.4.1 Emulated and Non-Emulated Data Sources

Some of the performance related configuration options have different affects, depending on the type of the data source. OC4J supports two types of data sources, emulated data sources and non-emulated data sources.

The pre-installed default data source is an emulated data source. Emulated data sources are wrappers around Oracle or non-Oracle data sources. If you use these data sources, your connections are extremely fast because they do not provide full XA or JTA global transactional support. We recommend that you use these data sources for local transactions or when your application requires access or update to a single database. You can use emulated data sources for Oracle or non-Oracle databases.

You can use emulated data sources to obtain connections to different databases by changing the values of the url and connection-driver parameters.

The following provides an example of a definition of an emulated data source:

<data-source
  class="com.evermind.sql.DriverManagerDataSource"
  name="OracleDS"
  location="jdbc/OracleCoreDS"
  xa-location="jdbc/xa/OracleXADS"
  ejb-location="jdbc/OracleDS"
  connection-driver="oracle.jdbc.driver.OracleDriver"
  username="scott"
  password="tiger"
  url="jdbc:oracle:thin:@localhost:5521:oracle"
  inactivity-timeout="30"
/>

Non-emulated data sources are pure Oracle data sources. You use non-emulated data sources for applications that need to coordinate access to multiple sessions within the same database or to multiple databases within a global transaction.

6.4.2 Using the EJB Aware Location Specified in Emulated Data Sources

The ejb-location only applies to emulated data sources. Each data source is configured with one or more logical names that allow you to identify the data source within J2EE applications. The ejb-location is the logical name of an EJB data source. In addition, use the ejb-location name to identify data sources for most J2EE applications, where possible, even when not using EJBs. You can use this option for single phase commit transactions or emulated data sources.

The ejb-location only applies to emulated data sources. Using the ejb-location, the data source manages opening a pool of connections, and manages the pool. Opening a connection to a database is a time-consuming process that can sometimes take longer than the operation of getting the data. Connection pooling allows client requests to have faster response times, because the applications do not need to wait for database connections to be created. Instead, the applications can reuse connections that are available in the connection pool.

6.4.3 Setting the Maximum Open Connections in Data Sources

The max-connections option specifies the maximum number of open connections for a pooled data source. To improve system performance, the value you specify for the number max-connections depends on a combination of factors including the size and configuration of your database server, and the type of SQL operations that your application performs.

The default value for max-connections and the handling of the maximum depends on the data source type, emulated or non-emulated.

For emulated data sources, there is no default value for max-connections, but the database configuration limits that affect the number of connections apply. When the maximum number of connections, as specified with max-connections, are all active, new requests must wait for a connection to be become available. The maximum time to wait is specified with wait-timeout.

For non-emulated data sources, there is a property, cacheScheme, that determines how max-connections is interpreted. Table 6-3 lists the values for the cacheScheme property (DYNAMIC_SCHEME is the default value for cacheScheme).

The tradeoffs for changing the value of max-connections are:

• For some applications you can improve performance by limiting the number of connections to the database (this causes the system to queue requests in the mid-tier). For example, for one application that performed a combination of updates and complex parallel queries into the same database table, performance was improved by over 35% by reducing the maximum number of open connections to the database by limiting the value of max-connections.

  
  

  Note: You should check to make sure that your database is configured to allow at least the total number of open connections, as specified by the data sources max-connections option for all your J2EE applications.

  
  

6.4.4 Setting the Minimum Open Connections in Data Sources

The min-connections option specifies the minimum number of open connections for a pooled data source.

For applications that use a database, performance can improve when the data source manages opening a pool of connections, and manages the pool. This can improve performance because incoming requests don't need to wait for a database connection to be established; they can be given a connection from one of the available connections, and this avoids the cost of closing and then reopening connections.

By default, the value of min-connections is set to 0. When using connection pooling to maintain connections in the pool, specify a value for min-connections other than 0.

For emulated and non-emulated data sources, the min-connections option is treated differently.

For emulated data sources, when starting up the initial min-connections connections, connections are opened as they are needed and once the min-connections number of connections is established, this number is maintained.

For non-emulated data sources, after the first access to the data source, OC4J then starts the min-connections number of connections and maintains this number of connections.

Limiting the total number of open database connections to a number your database can handle is an important tuning consideration. You should check to make sure that your database is configured to allow at least as large a number of open connections as the total of the values specified for all the data sources min-connections options, as specified in all the applications that access the database.

6.4.5 Setting the Cached Connection Inactivity Timeout in Data Sources

For emulated and non-emulated data sources, the inactivity-timeout specifies the time, in seconds, to cache unused connections before closing them.

To improve performance, you can set the inactivity-timeout to a value that allows the data source to avoid dropping and then re-acquiring connections while your J2EE application is running.

The default value for the inactivity-timeout is 60 seconds, which is typically too low for applications that are frequently accessed, where there may be some inactivity between requests. For most applications, to improve performance, we recommend that you increase the inactivity-timeout to 120 seconds.

To determine if the default inactivity-timeout is too low, monitor your system. If you see that the number of database connections grows and then shrinks during an idle period, and grows again soon after that, you have two options: you can increase the inactivity-timeout, or you can increase the min-connections.

6.4.6 Setting the Wait for Free Connection Timeout in Data Sources

For emulated and non-emulated data sources, the wait-timeout specifies the number of seconds to wait for a free connection if the connection pool does not contain any available connections (that is, the number of connections has reached the limit specified with max-connections and they are all currently in use).

If you see connection timeout errors in your application, increasing the wait-timeout can prevent the errors. The default wait-timeout is 60 seconds.

If database resources, including memory and CPU are available and the number of open database connections is approaching max-connections, you may have limited max-connections too stringently. Try increasing max-connections and monitor the impact on performance. If there are not additional machine resources available, increasing max-connections is not likely to improve performance.

You have several options in the case of a saturated system:

• Increase the allowable wait-timeout.

• Evaluate the application design for potential performance improvements.

• Increase the system resources available and then adjust these parameters.

6.4.7 Setting the Connection Retry Interval in Data Sources

The connection-retry-interval specifies the number of seconds to wait before retrying a connection when a connection attempt fails.

If the connection-retry-interval is set to a small value, or a large number of connection attempts is specified with max-connect-attempts this may degrade performance if there are many retries performed without obtaining a connection.

The default value for the connection-retry-interval is 1 second.

6.4.8 Setting the Maximum Number of Connection Attempts in Data Sources

The max-connect-attempts option specifies the maximum number of times to retry making a connection. This option is useful to control when the network is not stable, or the environment is unstable for any reason that sometimes makes connection attempts fail.

If the connection-retry-interval option is set to a small value, or a large number of connection attempts is specified with max-connect-attempts this may degrade performance if there are many retries performed without obtaining a connection.

The default value for max-connect-attempts is 3.

6.4.9 Setting the JDBC Statement Cache Size in Data Sources

To lower the overhead of repeated cursor creation and repeated statement parsing and creation, you can use statement caching with database statements. To enable JDBC statement caching, which caches executable statements that are used repeatedly, configure a datasource to use statement caching. A JDBC statement cache is associated with a particular physical connection maintained by a datasource. A statement cache is not per datasource so it is not shared across all physical connections. The JDBC statement cache is maintained in the middle-tier (not in the database server).

You can dynamically enable and disable statement caching programmatically using the setStmtCacheSize() method on the connection object.

To configure JDBC statement caching for a datasource, use the stmt-cache-size attribute to set the size of the cache. This attribute sets the maximum number of statements to be placed in the cache. If you do not specify the stmt-cache-size attribute or set it to zero, the statement cache is disabled.

The following XML sets the statement cache size to 200 statements.

<data-source>
 ...
stmt-cache-size="200"
</data-source>

To set the stmt-cache-size attribute, first determine how many distinct statements the application issues to the database. Then, set the size of the cache to this number. If you do not know the number of statements that your application issues to the database, you can use the JDBC performance metrics to assist you with determining the statement cache size. To use the statement metrics you need to set the Java property oracle.jdbc.DMSStatementMetrics to true for the OC4J.

6.4.10 Setting the JDBC Prefetch Size for a CMP Entity Bean

You can use the prefetch-size parameter to change the data source behavior for a JDBC query from a CMP Entity bean. However, this parameter is configured in orion-ejb-jar.xml rather than in data-sources.xml.

6.4.11 Using Application Server Control to Change Data Source Configuration Options

Figure 6-2 shows the Oracle Enterprise Manager 10g Application Server Control Console configuration page that lets you view or modify a data source. To see this page in Application Server Control Console from an OC4J instance, do the following:

1. Under the System Components table click and open the page for the OC4J instance on the Application Server Home page.

2. Click the Administration link on the OC4J instance page.

3. Click Data Sources Under Application Defaults.

4. Select a data source and Click Edit (or you can select data sources from the administration section of a deployed application's description page. This is only available when the application has its own local data source).

Application Server Control Console stores the data source elements that you add or modify in an XML file. This file defaults to the name data-sources.xml, located in $ORACLE_HOME/j2ee/home/config. If you want to change the name or the location of this file, you can do this in the General Properties page off of the default application screen or off of your specific application's page, when the application specifies a local data source.

Figure 6-2 Application Server Control Console Data Sources Configuration Page

Description of "Figure 6-2 Application Server Control Console Data Sources Configuration Page"

6.5.1 Setting the OC4J Transaction Configuration Timeout in server.xml

You can change the default value for the transaction configuration timeout in the transaction-config element in the server.xml file for the OC4J instance. This configuration parameter specifies the maximum time taken for a transaction to finish before it can get rolled back due to a timeout, and applies to all transactions on the OC4J instance.

By default server.xml sets the transaction-config to 30000 (30 seconds). You can change the transaction-config timeout value for applications that are getting transaction timeout errors, or if you know the transactions take longer than 30 seconds (including the time for waiting for connections set by wait-timeout in datasources.xml).

To change the transaction-config timeout value, change the following line in server.xml. For example, the following line in server.xml sets the transaction-config timeout parameter to 60 seconds:

<transaction-config timeout="60000"/>

The transaction-config timeout attribute applies for all transactions running in OC4J, and therefore must be big enough for your longest transaction (the transaction-config timeout applies for all transactions at the EJB level). Thus, set the transaction-config timeout attribute to a value greater than or equal to other transaction related attributes (for example the data sources wait-timeout and the EJB call-timeout).

6.5.2 Setting the OC4J Task Manager Granularity in server.xml

The OC4J task manager is an OC4J background process that performs cleanup operations, including the task of timing out HttpSessions. The task manager runs at regular intervals. Using the taskmanager-granularity attribute in server.xml, you can manage when the task manager runs. This attribute sets how often the task manager performs its cleanup operations. The value specified is in milliseconds and the default value is 1000 milliseconds.

The default taskmanager-granularity interval is usually adequate. If you modify the default value and set the value too high, such as to a value greater than 60000, one minute, this can delay the task of timing out of HttpSessions, which could lead to an OutOfMemory error (if you use HttpSessions).

For example, the following entry in server.xml sets taskmanager-granularity to 60000 milliseconds (1 minute).

<application-server ...  taskmanager-granularity="60000" ...>

6.5.3 Setting the OC4J Options for Stateful Session Bean Passivation in server.xml

OC4J automatically performs passivation of stateful session beans unless you set the enable-passivation attribute for the element <sfsb-config> to false. The default value for the attribute enable-passivation is true, which means that stateful session bean passivation occurs. If you have a situation where stateful session beans are not in a state to be passivated, set this attribute to false.

6.5.4 Limiting Concurrency In OC4J

OC4J contains a thread pooling mechanism for use in standalone OC4J. The OC4J server.xml global thread pool attributes control the number of threads that OC4J uses. In an Oracle Application Server 10g environment, we recommend that you do not specify <global-thread-pool> in server.xml. You can use this parameter to control the number of threads when using standalone OC4J (that is, when you are not in an Oracle Application Server 10g environment).

To limit concurrency in an Oracle Application Server 10g environment, we recommend using the Oracle HTTP Server MaxClients directive. When OC4J runs in an Oracle Application Server 10g environment, mod_oc4j works with OC4J to control OC4J concurrency. In this environment, limiting the number of threads by specifying <global-thread-pool> attributes in server.xml can cause resource contention issues that may result in deadlocks.

6.5.5 Using Application Server Control Console to Change server.xml Configuration Options

To update and configure options in server.xml using Application Server Control Console, first select the OC4J instance you want to modify. Then, select the Administration link and select the Advanced Properties link from the Instance Properties area. On the Advanced Server Properties page, select the server.xml link. On the edit server.xml page, select and modify the elements and attributes that you need to change. Finally, click Apply to apply the changes.

If you do not use Application Server Control Console, then edit server.xml in the $ORACLE_HOME/j2ee/instance_name/config directory, and use the dcmctl command to update the Oracle Application Server configuration as follows:

% dcmctl updateconfig -ct oc4j
% dcmctl restart -ct oc4j

6.6.1 Improving Performance by Altering Servlet Configuration Parameters

This section covers the following:

• Loading Servlet Classes at Startup

• Reducing Requests for Static Pages and Images

• Setting the Servlet Session Timeout

<servlet>
      <servlet-name>viewsrc</servlet-name>
      <servlet-class>ViewSrc</servlet-class>
      <load-on-startup> </load-on-startup>
</servlet>

6.6.2 Servlet Performance Tips

The following tips can enable you to avoid or debug potential performance problems:

• Analyze Servlet Duration

• Understand Server Request Load

• Find Large Servlets That Require a Long Load Time

• Watch for Unused Sessions and Session Invalidation

• Load Servlet Session Security Routines at Startup

session.Activation.active:       500 ops
session.Activation.completed:      0 ops

session.Activation.active:         2 ops
session.Activation.completed:    500 ops

6.7.1 Improving Performance by Altering JSP Configuration Parameters

This section describes JSP configuration parameters that you can alter to improve and control JSP operation. These parameters are set for each OC4J instance by altering the file global-web-application.xml.

This section covers the following topics:

• Using the main_mode Parameter

• Using the tags_reuse_default Parameter

• Additional JSP and OC4J Configuration Parameters

6.7.2 Improving Performance by Tuning JSP Code

This section describes changes you can make to your JSP code to improve performance.

This section covers the following topics:

• Impact of Session Management on Performance

• Using Static Template Text Instead of out.print for Outputting Text

• Performance Issues for Buffering JSPs

• Using Static Versus Dynamic Includes

<%@ page session="false" %>

HttpSession session;
session = httpRequest.getSession(true);
.
.
.
session.invalidate();

<%
  out.print("<HTML> <HEAD> <TITLE>Bookstore Home Page</TITLE></HEAD>\n");
  out.print("<BODY BGCOLOR=\"#ffffff\">\n");
  out.print("<H1 ALIGN=\"center\">Book Store Web Commerce Test</H1>\n");
  out.print("<P ALIGN=\"CENTER\">\n");
  out.print("<IMG SRC=\"../bookstore/Images/booklogo.gif\" ALIGN=\"BOTTOM\""+
              "BORDER=\"0\" WIDTH=\"288\" HEIGHT=\"67\"></P>\n");
  out.print("<H2 ALIGN=\"center\">Home Page</H2>\n");
%>
<jsp:useBean  id="randomid"  class="bookstore.BOOKS_Util" scope="request" >
<%
  random_id = randomid.getRandomI_ID();
%>

<HTML> <HEAD> <TITLE>Bookstore Home Page</TITLE></HEAD>
<BODY BGCOLOR=\"#ffffff\">
<H1 ALIGN=\"center\">Bookstore Web Commerce Test </H1>
<P ALIGN=\"CENTER\">
<IMG SRC=\"../bookstore/Images/booklogo.gif\" ALIGN=\"BOTTOM\""+
         "BORDER=\"0\" WIDTH=\"288\" HEIGHT=\"67\"></P>
<H2 ALIGN=\"center\">Home Page</H2>
<jsp:useBean  id="randomid"  class="bookstore.BOOKS_Util" scope="request" >
<%
  random_id = randomid.getRandomI_ID();
%>

<%@ page buffer="none" %>

<%@ page buffer="24KB" %>

<%@ include file="/jsp/userinfopage.jsp" %>

<jsp:include page="/jsp/userinfopage.jsp" flush="true" />

6.8.1 Configuring Parameters that Apply for All EJBs (Except MDBs)

Table 6-5 lists parameters that you can tune for EJB performance that are specific to OC4J. These parameters apply for all types of EJBs, including session and entity beans (except MDBs).

Table 6-5 shows parameters that are specified in orion-ejb-jar.xml.

This section also covers the following topic:

• EJB Timeouts Using a Non-default taskmanager-granularity

6.8.2 Configuring Parameters for CMP Entity Beans

This section covers parameters for entity beans using CMP. These parameters are specified in the orion-ejb-jar.xml configuration file.

Table 6-6 lists the entity bean CMP specific parameters.

Table 6-7 describes the supported locking-mode parameter values.

This section also covers the following CMP topics:

• Configuring Lazy-loading on CMP Entity Bean Finder Methods

• Setting the Batch Size Option to Batch UPDATE statements

The locking-mode, along with isolation, assures database consistency for EJB entity beans using CMP. Table 6-8 shows the common locking-mode and isolation combinations. The different combinations have both functional and performance implications, but often the functional requirements for data consistency will lead to selecting a mode, even when it may be at the expense of performance.

In Table 6-8 the isolation setting refers to either the transaction isolation attribute setting, if explicitly set, or to the database isolation level (if the transaction isolation attribute is not set). Also, although locking-mode and transaction isolation levels are set as attributes of a CMP bean, the isolation level that will be in effect for the transaction is the isolation level of the first entity bean used in the transaction. Therefore it is best to set all beans in the same transaction to the same isolation level.

In general, optimistic locking with committed isolation will be faster since it allows for more concurrency, but it may not meet your needs for data consistency. Pessimistic locking with committed isolation, and optimistic locking with serializable isolation will be slower, but will guarantee data consistency on updates.

Defining a bean as read-only will assure that no updates are allowed to the bean. The performance will be similar to a bean which may not be defined as read-only, and yet is never used to do inserts, updates, or deletes (that is, only the methods which read are called). This is because if no fields are modified in a bean that is not defined with read-only locking, it is already optimized to not do an ejbStore. To see a performance advantage and avoid doing ejbLoads for read-only beans, you must also set exclusive-write-access=true.

<entity-deployment ... findByPrimaryKey-lazy-loading="true" ... >

<finder-method ... lazy-loading="true" ...>
...
</finder-method>

6.8.3 Configuring Parameters for BMP Entity Beans

This section covers parameters that apply to entity beans using BMP. These parameters are specified in the orion-ejb-jar.xml configuration file.

Table 6-9 lists the entity bean BMP specific parameters.

6.8.4 Configuring Parameters for Session Beans

This section covers the parameters that are specified in the orion-ejb-jar.xml configuration file and apply for session beans.

Table 6-10 lists the stateless session bean specific parameters.

Table 6-11 lists the stateful session bean specific parameters.

This section also covers the following topic:

• Configuring Stateful Session Bean Passivation

• Stateful Session Bean Passivation Performance Recommendations

idletime=never
passivate-count=0
max-instances=0
max-instances-threshold=never
memory-threshold=never
resource-check-interval=never

6.8.5 Configuring Parameters for Message Driven Beans (MDBs)

This section covers the EJB parameters specified in the orion-ejb-jar.xml configuration file that apply for Message Driven Beans (MDBs).

Table 6-12 lists the MDB specific parameters.

destination.value:        name
messageDequeued.count:    x ops
messageEnqueued.count:    x ops
messageCount.value:  n

6.9.1 Avoiding Web Services Initial Request Delay

Oracle Application Server Web Services may experience an initial request delay due to the work required to validate data types and to generate server skeleton code. As a result, the initial Web Service request takes substantially longer than subsequent requests. In our tests, we see the first test taking 5 to 10 times as long as subsequent requests. The delay is increased when Java Beans are used to represent complex parameter and result sets.

To prevent this delay, send a request to Web Services on the system when the system is restarted or when the application is redeployed. You can also produce a script to send the initial Web Service request.

6.9.2 Using Web Services Typed Requests

There is a performance overhead associated with using Web Services untyped requests. When possible, develop clients that use typed requests as un-typed requests will take more time on the first request when the SOAP Mapping registry is created for the operation types.

6.9.3 Tuning the Web Services Stateful Session Timeout

When using Stateful Session based Web Services, tuning the session-timeout property for session-scoped stateful applications can provide performance benefits. The HTTP session timeout is specified in the web.xml configuration file as the <session-timeout> sub-element of the <session-config> element.

6.10.1 Choose the Right Deployment Configuration

Your application will have the best performance and scalability if you deploy your business components to the web module with your client. Unless you have strong reasons (such as wanting to use distributed transactions or EJB security features), we recommend web module deployment of business components over EJB deployment.

Note that both web module deployment and EJB deployment are fully J2EE-compliant, and the ADF framework makes it easy to switch between them. You can test your application in both modes to see which gives you the best performance.

6.10.2 Use Application Module Pooling for Scalability

A client can use application module instances from a pool, called application module pooling. This offers these advantages:

• It reduces the amount of time to obtain server-side resources

• It allows a small number of instances to serve a much larger number of requests

• It addresses the requirements of web applications that must handle thousands of incoming requests

• It lets you preserve session state and provides failover support

For example, in the case of a web application, you may have 1,000 users but you know that only 100 will be using a certain application module at one time. So you use an application module pool. When a client needs an application module instance, it takes a free one from the pool and releases it to the pool after either committing or rolling back the transaction. Because the instance is precreated, end users are saved the time it takes to instantiate the application module when they want to perform a task. Typically, web-based JSP clients use pools. If you want to make sure that the application module pool has a maximum of 100 application module instances, you can customize the default application module pool.

6.10.3 Perform Global Framework Component Customization Using Custom Subclasses

Particularly in large organizations, you may want specific functionality shared by all components of a particular type--for example, by all view objects. An architect can create a thin layer of classes such as MyOrgViewObjectImpl that implement the desired behavior. Individual developers can extend MyOrgViewObjectImpl instead of ViewObjectImpl, and you can use the "substitutes" feature to extend MyOrgViewObjectImpl in legacy code.

6.10.4 Use SQL-Only and Forward-Only View Objects when Possible

Basing a view object on an entity object allows you to use the view object to insert, update, and delete data, and helps keep view objects based on the same data synchronized. However, if your view object is only going to be used for read-only queries, and there is no chance that the data being queried in this view object will have pending changes made through another view object in the same application module, you should use a SQL-only view object that has no underlying entities. This will give you improved performance, since rows do not need to be added to an entity cache.

If you are scrolling through data in one direction, such as formatting data for a web page, or for batch operations that proceed linearly, you can use a forward-only view object. Forward-only mode prevents data from entering the view cache. Using forward only mode can save memory resources and time, because only one view row is in memory at a time. Note that if the view object is based on one or more entity objects, the data does pass to the entity cache in the normal manner, but no rows are added to the view cache.

6.10.5 Do Not Let Your Application Modules Get Too Large

A root application module should correspond to one task--anything that you would include in a single database transaction. Do not put more view objects or view links than you will need for a particular task in a single application module.

In addition, consider deferring the creation of view links by creating them dynamically with createViewLink(). If you include all view links at design time, the business logic tier will automatically execute queries for all detail view objects when your client navigates through a master view object. Deferring view link creation will prevent the business logic tier from executing queries for detail view objects that you do not yet need.

For example, for a form in which detail rows are displayed only on request (rather than automatically), including a view link at design time would force the business logic tier to automatically execute a query that might well be unnecessary. To prevent this, you should create a view link dynamically when the detail rows are requested. By contrast, for a form in which detail rows are displayed as soon as a master is selected, you should use a view link created at design time to avoid the runtime overhead of calling createViewLink().

6.10.6 Use the Right Failover Mode

By default, the application module pool supports failover, which saves an application module's state to the database as soon as the application module is checked into the pool. If the business logic tier or the database becomes inoperable in mid-transaction (due to a power failure or system malfunction, for example), the client will be able to instantiate a new application module with the same state as the lost one, and no work will be lost.

However, some applications do not require this high level of reliability. If you're not worried about loss of work due to server problems, you may want to disable failover. When failover is disabled, the application module's state exists only in memory until it is committed to the database (at which point the application module's state is discarded) or recycled (at which point the state is saved so that the client can retrieve it). By not saving the application module state every time the application module is checked in, failover-disabled mode can improve performance.

6.10.7 Use View Row Spillover to Lower the Memory to Cache a Large Number of Rows

While the business logic tier is running, it stores view rows in a cache in memory (the Java heap). When the business logic tier needs to store many rows at once, you need to make sure it doesn't run out of memory. To do so, you can specify that when the number of rows reaches a certain size, the rows "overflow" to your database to be stored on disk. This feature is called view row spillover. If your application needs to work with a large query result, view row spillover can help the cache operate more efficiently.

6.10.8 Choose the Right Style of Bind Parameters

Oracle-style bind parameters (:1, :2, and so on) are more performant than JDBC-style bind parameters.

Only use JDBC-style bind parameters if you may use a non-oracle JDBC driver.

6.10.9 Implement Query Conditions at Design Time if Possible

You should include any portion of your query condition that you know in advance in the WHERE clause field in the View Object wizard. Only use setWhereClause() for genuinely dynamic query conditions.

Even if your query conditions are genuinely dynamic, you may be able to use parametrized queries instead of setWhereClause(). For example, if your view object needs to execute a query with the WHERE clause EMPLOYEE_ID=<x> for various values of x, use a parametrized WHERE clause such as EMPLOYEE_ID=:1. This is more efficient than repeatedly calling setWhereClause().

6.10.10 Use the Right JDBC Fetch Size

The default JDBC fetch size is optimized to provide the best tradeoff between memory usage and network usage for many applications. However, if network performance is a more serious concern than memory, consider raising the JDBC fetch size.

6.10.11 Turn off Event Listening in View Objects used in Batch Processes

In non-interactive, batch processes, there is no reason for view objects to listen for entity object events. Use ViewObject.setListenToEntityEvents(false) on such view objects to eliminate the performance overhead of event listening.

6.11.1 Improving JAZN Performance With an XML Provider

When OC4J with JAZN is configured to use the XML provider, JAZN loads the entire XML file into a data structure in memory for fast access. In terms of performance, this process incurs a small start-up cost, but if the file is not too large and the data in the file can be retained in physical memory, data access will be very efficient and JAZN operations should incur little overhead.

6.11.2 Improving JAZN Performance With an LDAP Provider (Oracle Internet Directory)

When OC4J applications using JAZN are configured to use an LDAP provider, the LDAP repository is queried for data on demand. In this case, a single operation may involve multiple accesses to a remote directory, and the overhead for JAZN protection can become significant. Such overhead can be even greater if secure communications are required between OC4J and the repository which typically requires using SSL. When JAZN is configured to communicate with the LDAP repository using SSL, the performance issues of the SSL protocol should be considered.

There are several configuration choices to make when you set up SSL between OC4J, and LDAP (Oracle Internet Directory). SSL can be configured to use encryption only, or encryption plus client or server authentication.

To alleviate the costs of communicating with an LDAP repository, OC4J JAZN provides caches, including the following three separate caches:

• The Policy Cache: stores grantees and permissions

• The Realm Cache: stores realms, users and roles

• Session cache: stores users and roles in an HTTP session object

The JAZN-LDAP caches are implemented as a single, in-memory hashtable. Objects in the cache are expired based on a configurable timeout value. A daemon thread runs periodically, at the timeout interval, to clean up expired objects in the cache. Each of the three caches can be enabled or disabled, and the initial capacity, load factor, initial cache purge delay, and cache purge timeout value can all be specified.

By default, the JAZN LDAP Provider is configured to use caching. Caching greatly improves the efficiency of using JAZN with an LDAP-based repository. Our experiments have shown the default values of cache configuration often work well, but you may need to test these values to determine how your application performs using JAZN.

6.11.3 Configuring JAZN Providers

Oracle Application Server OC4J provides an integrated JAAS implementation with OC4J. To configure the JAAS provider, you use jazn.xml to determine if the provider is LDAP-based, uses Oracle Internet Directory as the data store, or XML based.

The file jazn.xml is the configuration file for both the XML-based and LDAP-based JAAS providers. The JAAS Provider must locate a valid jazn.xml file before it can begin running.When the JAAS provider starts up, it searches for jazn.xml in order through the directories specified by:

1. oracle.security.jazn.config (system property)

2. java.security.auth.policy (system property)

3. $J2EE_HOME/config ($J2EE_HOME is specified by the system property oracle.j2ee.home)

4. $ORACLE_HOME/j2ee/home/config ($ORACLE_HOME is specified by the system property oracle.home)

5. . ./config

The JAAS provider stops searching after locating a jazn.xml file. If no file is found, you receive the error message "JAZN has not been properly configured."

You can also use the <jazn> tag to configure the JAAS Provider. The <jazn> tag can appear in any of the following locations:

• The application's orion-application.xml

• The global application.xml

• jazn.xml

6.11.4 JAZN Performance Recommendations

The following recommendations should help you to meet the performance requirements for applications that use JAZN for authentication and authorization:

1. If the JAZN XML file-based repository is sufficient for your needs, it is likely to provide the best performance.

2. If an LDAP repository is required, for management, usability, or scalability reasons, use the JAZN-LDAP caches. Configure the cache parameters as needed to improve performance.

3. If an LDAP repository is required, and if secure communications are needed between the LDAP repository and OC4J, configure the system to use only the level of security required. For example, use encryption only if that is sufficient.

6.13.1 Configuring Multiple OC4J Processes

This section covers the following:

• Overview of Types of OC4J Configurations

• Determining the Number of OC4J Processes

• Partitioning Applications into Different OC4J Instances

• Configuring Multiple OC4J Processes Using Application Server Control Console

6.13.2 Load Balancing Applications

OC4J provides load-balancing features for web-based applications with HTTP clients and for EJB applications accessed by remote Java EJB clients.

This section covers the following topics:

• Web Application Load Balancing

• EJB Application Load Balancing

opmn:ormi://opmn_host:opmn_port:oc4j_instance/application-name

ormi://hostname:ormi_port/application-name

java.naming.provider.url=ormi://host1:23791/my_ejb_app,ormi://host2:23792/my_ejb_app,ormi://host3:23791/my_ejb_app

6.13.3 Limiting Connections

This section covers the following topics:

• Limiting Web Connections

• Limiting Remote EJB Client Connections

• Limiting HTTP Connections with Standalone OC4J

<max-http-connections max-connections-queue-timeout="120" socket-backlog="50" value="100"/>

<max-http-connections max-connections-queue-timeout="120" socket-backlog="50" value="100"> http://example.com/page.jsp 
</max-http-connections>

6.13.4 Controlling Replication With Multiple OC4Js

This section covers the following:

• Controlling Web Application Replication

• Controlling Stateful Session EJB Replication

6.14.1 Deployment Performance During the Application Development Phase

The following development phase choices have an impact on application deployment time for applications that are deployed to OC4J.

• JVM flags – The JVM –server flag is recommended for production use and is the default for OC4J when running in an Oracle Application Server environment. We have found –server usually improves performance in server environments. However, using the –server option increases the time required to restart a JVM and can require more memory.

  
  

  See Also: "Setting Java Command Line Options (Using JVM and OC4J Performance Options)"

  
  

• Heap requirements – When you deploy large applications, if the deployment triggers JVM garbage collection, you may improve performance by increasing the size of the heap. Increasing the heap may provide enough memory so that the garbage collection is avoided. To increase the size of the heap, use either the –Xmx JVM option or set the -XX:+AggressiveHeap option. In addition, if the system is constrained for physical memory you may wish to shut down unused OC4J instances to reclaim physical memory.

  
  

  See Also: "Setting the JVM Heap Size for OC4J Processes" "Setting the JVM AggressiveHeap Option for OC4J Processes"

  
  

• Application Type – EJB applications require a compilation phase during deployment, and typically take longer to deploy than other type of J2EE applications.

• Browser type – The default configuration of Internet Explorer uses a buffer size of 8K. This size limitation can cause a delay in transmitting large files which can result in a significant performance degradation on deployments of large applications. We advise changing the configuration option to increase the buffer size. For detailed instructions on changing the buffer size, see the following site,

  http://support.microsoft.com/default.aspx?scid=kb;en-us;329781

  This issue is also present with Netscape 7.0 and Mozilla 1.0.2., however we are not aware of any workarounds. If you are using these browsers, you may decide to use a different browser or manually copy the .ear file to the local host and deploy using a command line tools (admin.jar or dcmctl). Netscape versions 4.79 and 7.1 do not exhibit this problem.

• File system utilization – Deploying applications involves file I/O to the local deployment directory. File I/O speeds may be impacted by the percentage utilization of the file system. Consult your platform documentation for recommendations about optimal utilization levels. However, many platform vendors recommend maintaining file system utilization below 90% for optimal performance.

• Batch Mode or Non-Batch Mode – EJB applications require a compilation phase during deployment, and typically take longer to deploy than other types of J2EE applications. You can specify non-batch mode if you find that OC4J throws java.lang.OutOfMemory exceptions while compiling in batch mode (the default). If you encounter this exception, you may want to try selecting non-batch mode, as it requires less memory allocation. However, using this mode can slow the deployment.

  
  

  See Also: "Setting the OC4J EJB Wrapper Class Compilation Mode"

  
  

6.14.2 Deployment Performance During the Test and Production Phases

The following test or production phase choices have an impact on the time it takes to deploy an application to OC4J.

• Deployment Tool – For production use with Oracle Application Server, you must deploy applications using either: dcmctl, Application Server Control Console, or JDeveloper. If you use dcmctl to deploy applications and need to perform multiple deploys or management commands, using the dcmctl shell mode provides a minor performance savings. Using the shell mode, the dcmctl client maintains a single client process for all the commands you run.

• Repository Type – If you are using an Oracle Application Server with a database repository, where the repository runs on a remote host, you may see slightly higher deployment times depending on the network latency at your site. Deploying to an Oracle Application Server with a local file-based repository usually is the most performant. Your choice of repository type should be driven by the availability and architectural requirements for your site and by application and deployment requirements.

  
  

  See Also: Oracle Application Server High Availability Guide

  
  

• Oracle HTTP Server Process State – As a final phase of application deployment, if the Oracle HTTP Server is running, OPMN issues a command to restart the Oracle HTTP Server. This action updates the routing information for the newly deployed application. If you have a number of applications to deploy, and you are not running in a live production environment, you may wish to leave the Oracle HTTP Server down until after all applications are deployed. This avoids repeated restarts for the Oracle HTTP Server. However, restarting the Oracle HTTP Server only takes a few seconds, depending on the system speed, so the performance savings is not dramatic unless you are deploying a large number of applications.

• OC4J Process State – If the OC4J instance that you wish to deploy to is not started at the time the deploy command is issued, OPMN will start the instance and then shut it down when the deployment is complete. Again, these restart times are primarily significant when you are deploying multiple applications.

• Heap requirements – When you deploy large applications, the deployment may trigger JVM garbage collection. In memory-constrained environments, where you cannot increase the size of the heap to provide enough memory so that the garbage collection is avoided, then, typically, the only result of a garbage collection is an increase in the application deployment time (and an increase in response times for requests to the OC4J instance or request timeouts). However, if the application being deployed is extremely large, the extended duration of the garbage collection may trigger OPMN to restart the OC4J instance.

  To avoid OC4J restarts, increase the OPMN ping failure limit by setting values for the no-reverseping-failed-ping-limit and reverseping-failed-ping-limit parameters in opmn.xml. For example, set these values as follows:

  <category id="restart-parameters">
     <data id="no-reverseping-failed-ping-limit" value="2"/>
     <data id="reverseping-failed-ping-limit" value="10"/> 
  </category>
  
  

  The default value for no-reverseping-failed-ping-limit is 1 and the default value for reverseping-failed-ping-limit is 3.

• Batch Mode or Non-Batch Mode – EJB applications require a compilation phase during deployment, and typically take longer to deploy than other types of J2EE applications. You can specify non-batch mode if you find that OC4J throws java.lang.OutOfMemory exceptions while compiling in batch mode (the default). If you encounter this exception, you may want to try selecting non-batch mode, as it requires less memory allocation. However, using this mode can slow the deployment.

  
  

  See Also: "Setting the OC4J EJB Wrapper Class Compilation Mode"