| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
This chapter provides guidelines for configuring OC4J and the Java compiler for deployment of large J2EE applications that contain large numbers of Enterprise JavaBeans (approximately 100 or more).
This chapter includes the following sections:
When you deploy an EJB 3.0 application with one or more annotations, OC4J will automatically write its in-memory ejb-jar.xml file to the same location as the orion-ejb-jar.xml file in the deployment directory. This ejb-jar.xml file represents configuration obtained from both annotations and a deployed ejb-jar.xml file (if present).
When an application containing EJB 2.1 JAR files is deployed, 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 nonbatch mode. Each is discussed below.
Batch Mode
This is the default compilation mode used by OC4J. In general, batch mode provides faster time to deployment when you are deploying large, EJB-heavy applications. However, it also requires a greater heap memory allocation than the nonbatch mode of deployment.
In this 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.
If the compiler is configured to run in out-of-process mode, which it is by default in OC4J, then OC4J will create a single JVM process to execute compilation of the wrapper code. See "Configuring Out-of-Process or In-Process Compiler Execution" for instructions on configuring the compiler to run out-of-process or in the same JVM process as OC4J.
Nonbatch Mode
If you find that OC4J throws java.lang.OutOfMemory exceptions while compiling in batch mode, you might want to compile in nonbatch mode instead because it requires less memory allocation. However, using this mode will result in a longer time to deployment.
In this mode, OC4J makes multiple calls to the compiler, one for each EJB JAR file within the EAR being deployed.
If the Java compiler is configured to run in out-of-process mode, OC4J will create a JVM process for each EJB JAR file included in the EAR file being deployed.
To deploy in nonbatch mode, set the batch-compile attribute of the <orion-application> element in application.xml or orion-application.xml to false. For example:
<orion-application ... batch-compile="false" .../>
Wrapper Code Debugging
By default, when OC4J deploys an EJB 2.1 CMP application, it generates wrapper code in the ORACLE_HOME/j2ee/instance/application-deployments/ear-name/ejb-name/generated directory, compiles the code, creates a JAR file that contains the compiled classes, and then deletes the wrapper code it generates. You can configure OC4J to preserve the wrapper code that it generates. Examining the wrapper code can aid in debugging some application problems.
|
Notes: Theejbdeploy.batch system property, which had been used to specify batch versus nonbatch compilation mode, is deprecated in OC4J (10.1.3.1.0)
Debugging generated wrapper code is also deprecated in this release. These options apply only to EJB 2.1 entity beans with container-managed persistence; they do not apply to session beans, message-driven beans, or EJB 3.0 entities. OC4J generates only one file for each EJB 2.1 entity bean with container-managed persistence. OC4J does not generate any artifacts if you use only EJB 3.0 entities. |
This section provides guidelines on configuring the Java compiler that will compile the EJB wrapper classes and JSPs during deployment. It includes the following topics:
Note that all compiler configuration parameters are specified as attributes of the <java-compiler> element in ORACLE_HOME/j2ee/instance/config/server.xml, the OC4J server configuration file.
By default, OC4J uses the javac compiler packaged with the Sun Microsystems JDK to compile generated EJB wrapper classes, JavaServer Pages, Web services classes, and any .java files packaged with an application. However, you can configure OC4J to use a different Java compiler by modifying the <java-compiler> element in server.xml with the alternative compiler configuration.
For example, the following notation will cause OC4J to use the Jikes compiler from IBM:
<java-compiler name="jikes" in-process="false"/>
The Java compiler can be configured within OC4J to execute in one of two modes: out-of-process or in-process.
Out-of-Process
In this mode, a separate JVM process is spawned for the compiler to execute within. This is the default compiler execution mode used by OC4J because it offers better management of memory resources. Once compilation of the EJB wrapper classes is complete, the memory allocated to the associated JVM will be released and made available to other processes.
Set the in-process attribute of the <java-compiler> element to false to execute the compiler in this mode.
In-Process
In this mode, the compiler executes within the same JVM process as OC4J. Set the in-process attribute of the <java-compiler> element to true to execute in this mode.
Table 4-1 summarizes the attributes of the <java-compiler> element, which defines the Java compiler configuration in server.xml, the OC4J configuration file.
Table 4-1 Attributes of the <java-compiler> Element
| Attribute | Description |
|---|---|
|
|
Value: string Default: javac Specifies the compiler name. Set to |
|
|
Value: string Specifies the absolute path to the compiler directory. This attribute does not need to be specified to use the default |
|
|
Value: Boolean Default: Indicates whether to execute the Java compiler in-process ( |
|
|
Used to pass command line options to the Java compiler. Separate multiple options with a space. For example: <java-compiler name="javac" options="-J-Xmx2048m -J-Xss=8m"/> |
|
|
Value: string Default: Specifies the source file encoding to use. |
|
|
Indicates the compiler extension library location. |
|
|
Value: Boolean Default: Set to |
In addition to setting the OC4J JVM heap size (young and old generations), you should also pay attention to the permanent generation size when deploying large applications.
The JVM permanent generation plays an important role when you are deploying large applications. Because a large application can contain hundreds or even thousands of EJBs, the OC4J JVM needs to load a large number of classes, which requires a higher value for permanent generation size.
If the permanent generation size is set too low, you may see java.lang.OutOfMemoryError errors from the JDK even if you have plenty of free memory in the heap. If this occurs, you can increase the permanent generation (Perm) size by setting the -XX:MaxPermSize property.
For example, to set the total heap size to 768 MB, set the following at OC4J startup:
java -Xms512m -Xmx512m -XX:MaxPermSize=256m -jar oc4j.jar
To determine the value for the -XX:MaxPermSize property - including young and old generation sizes - you can use visualgc to monitor the OC4J JVM during application deployment. The visualgc garbage collection monitoring tool is included with the free jvmstat 3.0 distribution available from Sun Microsystems. See the following Web site for more information and to download the tool:
http://java.sun.com/performance/jvmstat/
