Skip Headers

Oracle® Containers for J2EE Deployment Guide 10g Release 3 (10.1.3) Part No. B14431-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 3 Deploying Large Applications

This chapter provides guidelines for configuring OC4J and the Java compiler for deployment of large J2EE applications containing large numbers (~100) of Enterprise JavaBeans.

This chapter includes the following sections:

- Specifying the Compilation Mode to Use

- Configuring the Java Compiler

- Tuning the OC4J JVM for Large Deployments

## Specifying the Compilation Mode to Use

When an application containing EJB 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 non-batch 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 deploying large EJB-heavy applications. However, it also requires a greater heap memory allocation than non-batch mode 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 Versus In-process Compiler Execution" for instructions on configuring the compiler to run out-of-process or in the same JVM process as OC4J.

Non-Batch Mode

If you find that OC4J throws `java.lang.OutOfMemory` exceptions while compiling in batch mode, you may want to compile in non-batch mode instead, as 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 non-batch 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" .../>

Note: The `ejbdeploy.batch` system property, which had previously been used to specify batch versus non-batch compilation mode, is de-supported in this release of OC4J.

## Configuring the Java Compiler

This section provides guidelines on configuring the Java compiler that will compile the EJB wrapper classes, JSPs during deployment. It includes the following topics:

- Specifying an Alternative Java Compiler

- Configuring Out-of-process Versus In-process Compiler Execution

- Summary of Java Compiler Configuration Parameters

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.

### Specifying an Alternative Java Compiler

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"/>

### Configuring Out-of-process Versus In-process Compiler Execution

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, as 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.

### Summary of Java Compiler Configuration Parameters

Table 3-1 summarizes the attributes of the `<java-compiler>` element, which defines the Java compiler configuration in `server.xml`, the OC4J configuration file.

Table 3-1 Attributes of the <java-compiler> Element

Attribute | Description
--- | ---
`name` | Value: string Specifies the compiler name. Set to `javac` to use the Sun javac compiler.
`bindir` | Value: string Specifies the absolute path to the compiler directory. This attribute does not need to be specified to use the default `javac` compiler.
`in-process` | Value: Boolean Default: `false` Indicates whether to execute the Java compiler in-process (`true`) or out-of-process (`false`).
`options` | 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"/>
`encoding` | Value: string Default: `ISO-8859-1` Specifies the source file encoding to use.
`extdirs` | Indicates the compiler extension library location.
`debug` | Value: Boolean Default: `false` Set to `true` to generate compilation-time debugging output.

## Tuning the OC4J JVM for Large Deployments

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. Since a large application may 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 link for more information and to download the tool:

    http://java.sun.com/performance/jvmstat/