| Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g Release 3 (10.1.3) B14428-02 |
|
 Previous |
 Next |
| Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g Release 3 (10.1.3) B14428-02 |
|
Previous |
Next |
This section describes:
For more information, see:
Oracle Application Server Enterprise Deployment Guide
This section describes:
Tuning the VM to Avoid Out Of Memory Errors During Deployment
Disabling Batch Compilation to Avoid Out Of Memory Errors During Deployment
For more information, see "Deploying Large Applications" in the Oracle Containers for J2EE Deployment Guide.
If a very large application (EAR) is deployed to OC4J, an OutOfMemory exception may be thrown at deployment time.
Your VM heap and permanent space configuration can cause such an exception. By default, heap and permanent space is set to 64 MB.
If there is a heap space problem, the heap space should be specified as: java -Xmx750m -Xms512m.
If there is a permanent space problem, the permanent space should specified as: java -Xmx750m -Xms512m -XX:PermSize=128m -XX:MaxPermSize=256m.
If the deployment process is interrupted for any reason, you may need to clean up the temp directory, which by default is /var/tmp, on your system. The deployment wizard uses 20 MB in swap space of the temp directory for storing information during the deployment process. At completion, the deployment wizard cleans up the temp directory of its additional files. However, if the wizard is interrupted, it may not have the time or opportunity to clean up the temp directory. Thus, you must clean up any additional deployment files from this directory yourself. If you do not, this directory may fill up, which will disable any further deployment. If you receive an Out of Memory error, check for space available in the temp directory.
To change the temp directory, set the command-line option for the OC4J process to java.io.tmpdir=<new_tmp_dir>. You can set this command-line option in the Server Properties page. Drill down to the OC4J Home Page. Scroll down to the Administration Section. Select Server Properties. On this page, Scroll down to the Command Line Options section and add the java.io.tmpdir variable definition to the OC4J Options line. All new OC4J processes will start with this property.
If your application (EAR) contains multiple JAR files, you can try disabling batch deployment to fix OutOfMemory exceptions. However, if your EAR file only has one JAR file, this approach will not fix such exceptions: in this case, you must tune the VM (see "Tuning the VM to Avoid Out Of Memory Errors During Deployment").
If OC4J throws Out of Memory exceptions at deploy time, and you have already tried tuning the VM (see "Tuning the VM to Avoid Out Of Memory Errors During Deployment"), you may also attempt to compile in non-batch mode. Although non-batch mode requires less memory, this mode will result in a longer deployment time.
To enable or disable batch compilation, use the <application> element or <orion-application> attribute batch-compile.
The default value of batch-compile is true.
To disable batch compile, set this attribute to false.
Example 28-1 shows how to configure this attribute in the orion-applicatin.xml deployment descriptor.
Example 28-1 Disabling Batch Compilation in the orion-application.xml File
<orion-application batch-compile ="false"> ... </orion-application>
If out of memory errors persist, try disabling batch compile.
OC4J supports incremental or partial redeployment of EJB modules that are part of a deployed application. This feature makes it possible to redeploy only those beans within an EJB JAR that have changed to be deployed, without requiring the entire module to be redeployed. Previously deployed beans that have not been changed will continue to be used.
This functionality represents a significant enhancement over previous releases of OC4J, which treated an EJB module as a single unit, requiring that the module first be undeployed, then redeployed with any updates.
You can use the updateEBJModule command in both the admin.jar and admin_client.jar utilities to incrementally update a deployed application with one or more EJBs contained within an EJB JAR file.
A restart of OC4J is required only if changes are made to the EJB configuration data during the redeployment process. If no changes are made, a hot deployment can be performed without re-starting OC4J.
The incremental redeployment operation will automatically stop the application containing the EJB(s) to be updated, then automatically restart the application when finished.
|
Note: During redeployment, all idle client connections to the EJB being updated will be lost. All existing requests will be allowed to complete, but no new requests will be allowed until the application is restarted. It is strongly recommended that you stop the application before redeploying the EJB. |
The general procedure for using incremental deployment is:
Deploy an application with a large number of enterprise JavaBeans.
Change a bean-related class file in an EJB module and rebuild the EJB JAR file (for example, myBeans-ejb.jar).
Submit the updated EJB JAR to OC4J using any of the following:
JDeveloper
EnterpriseManager
<OC4J_HOME>\j2ee\home\admin.jar.
Example 28-2 shows how to use the admin.jar:
For more information see, "Incremental Redeployment of Updated EJB Modules" in the Oracle Containers for J2EE Deployment Guide.
When you deploy an EJB 3.0 application with one or more annotations, OC4J will write its in-memory ejb-jar.xml file to the same location as the orion-ejb-jar.xml file in the deployment directory: <ORACLE_HOME>/j2ee/home/application-deployments/my_application/META-INF.
This ejb-jar.xml file represents configuration obtained from both annotations and a deployed ejb-jar.xml file (if present).
For more information, see "Troubleshooting an EJB Application".
