Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 10g Release 3 (10.1.3) B14428-02 |
|
![]() Previous |
![]() Next |
This chapter describes:
For more information, see "Understanding EJB Administration".
OC4J deploys MBeans to collect JSR77 statistics and Oracle Dynamic Monitoring System (DMS) sensor data for all types of EJBs.
You can access these statistics and sensors using any JMX-compliant management tool, such as the Application Server Control (see "Using Oracle Enterprise Manager 10g Application Server Control").
The Application Server Control is a JMX-compliant, Web-based user interface for deploying, configuring and monitoring applications within OC4J, as well as managing the OC4J server instance and the Web services used by your applications.
Using the Application Server Control JMX administrative task, you can modify properties of all EJB types deployed to OC4J without having to restart Oracle Application Server or redploy your application:
Launch Application Server Control.
Click the Administration link.
Click System MBean Browser.
Specific MBean instances are accessed through the navigation pane to the left of the console. Expand a node in the navigation pane and drill down to the MBean you wish to access.
For example, for a standalone OC4J, select: J2EEServer > standalone > J2EEApplication > application-name > EJBModule > module-name
Select the type of EJB, such as StatelessSessionBean, MessageDrivenBean, or WebServicePort.
Select an MBean instance.
Click the appropriate tab in the right-hand pane:
Click the Attributes tab to access the MBean's attributes. If you modify any attribute values, click the Apply Changes button to apply your changes to the OC4J runtime.
Click the Operations tab to access the MBean's operations. After selecting a specific operation, click the Invoke button to call it
Click the Notifications tab to subscribe to the MBean's notifications. After selecting a specific notification, click the Apply button to subscribe to it.
Click the Statistics tab to view the MBean's statistics.
You can use Application Server Control for most administration tasks.
For more information, see:
"Oracle Enterprise Manager 10g Application Server Control Console" in the Oracle Containers for J2EE Configuration and Administration Guide
the online Help provided with Application Server Control
OC4J uses the standard JDK java.util.logging
package and, by default, writes log messages to the <
OC4J_HOME
>/j2ee/home/log/<group>/oc4j/log.xml
file.
This section describes:
You can configure loggers for the following java.util.logging
namespaces:
oracle.j2ee.ejb.annotation
oracle.j2ee.ejb.compilation
oracle.j2ee.ejb.database
oracle.j2ee.ejb.deployment
oracle.j2ee.ejb.lifecycle
oracle.j2ee.ejb.pooling
oracle.j2ee.ejb.runtime
oracle.j2ee.ejb.transaction
You can configure log levels of: FINER
, FINE
, CONFIG
, INFO
, WARNING
, and SEVERE
.
The simplest way to configure OC4J logging is to use Application Server Control (see "Using Oracle Enterprise Manager 10g Application Server Control").
Application Server Control shows all EJB-related logger names and you can specify attributes like log level using the Application Server Control interface.
You can configure OC4J logging using the <
OC4J_HOME
>/j2ee/home/config/j2ee-logging.xml
file as Example 31-1 shows.
Example 31-1 j2ee-logging.xml File
<logger name='oracle.j2ee.ejb' level='NOTIFICATION:1' useParentHandlers='false'> <handler name='oc4j-handler'/> <handler name='console-handler'/> </logger>
For more information, see:
You can configure OC4J logging using the oracle.j2ee.logging
system property. This system property has the form:
oracle.j2ee.logging.<log-level>=<log-namespace>
Where:
<log-level>
is one of fine
, finer
, or finest
.
<log-namspace>
is an oracle.j2ee.ejb namespace (see "Logging Namespaces").
Example 31-2 shows how to configure the logger for the oracle.j2ee.ejb.deployment namespace to finest.
OC4J provides EJB pooling attributes that you can configure to improve performance by reducing the frequency of bean instance creation.
This section describes:
You can set the minimum and maximum number of the bean instance pool for session beans, entities, and message-driven beans.
You can configure the bean pool size:
In the orion-ejb-jar.xml
file you set the bean pool size with the following attributes of the <entity-deployment>
element, for entities, and the <session-deployment>
element, for session beans:
The max-instances
attribute sets the maximum number of bean instances allowed in the pool. The default is 0, which means infinite. To disable bean pooling, set this value to a negative number.
For example, if you wanted to set the maximum entity implementation instances to 20, you would do as follows:
<entity-deployment ... max-instances="20" ... </entity-deployment>
The min-instances
attribute sets the minimum number of bean instances allowed in the pool.
For example, if you wanted to set the minimum entity implementation instances to 2, you would do as follows:
<entity-deployment ... min-instances="2" ... </entity-deployment>
If you change this property using this method, you must restart OC4J to apply your changes. Alternatively, you can use Application Server Control Console to modify this parameter dynamically without restarting OC4J (see "Using Oracle Enterprise Manager 10g Application Server Control").
You can set the maximum amount of time that session beans are cached in the bean instance pool.
You can configure pool timeouts for session beans:
In the orion-ejb-jar.xml
file you set the bean pool timeout with the following attributes of the <session-deployment>
element for session beans:
The pool-cache-timeout
attribute is applicable to stateless session beans and sets how long to keep stateless sessions cached in the pool. The default is 0 seconds, which means never timeout.
For example, if you wanted to set the pool-cache-timeout
to 90 seconds, you would do as follows:
<session-deployment ... pool-cache-timeout="90" ... </session-deployment>
The timeout
attribute is applicable to stateful session beans and sets how long a stateful session bean can remain inactive before it is removed from the bean instance pool. The default is 1800 seconds.
For example, if you wanted to set the stateful session bean inactivity timeout to 900 seconds, you would do as follows:
<sessi0n-deployment ... timeout="900" ... </session-deployment>
If you change this property using this method, you must restart OC4J to apply your changes. Alternatively, you can use Application Server Control Console to modify this parameter dynamically without restarting OC4J (see "Using Oracle Enterprise Manager 10g Application Server Control").
You can set the maximum amount of time that entities are cached in the bean instance pool.
You can configure pool timeouts for entities:
In the orion-ejb-jar.xml
file you set the bean pool timeout with the following attributes of the <entity-deployment>
element for entities:
The pool-cache-timeout
attribute sets how long entity bean implementation instances are to be kept in the "pooled" (unassigned) state. The default is 60 seconds. Setting this attribute to "never" means never timeout.
For example, if you wanted to set the pool-cache-timeout for entities to 90 seconds, you would do as follows:
<entity-deployment ... pool-cache-timeout="90" ... </entity-deployment>
If you change this property using this method, you must restart OC4J to apply your changes. Alternatively, you can use Application Server Control Console to modify this parameter dynamically without restarting OC4J (see "Using Oracle Enterprise Manager 10g Application Server Control").
You can use Application Server Control to stop and start an EJB application.
While an application is stopped, clients cannot access it.
For more information, see "Using Oracle Enterprise Manager 10g Application Server Control".
This section describes:
To configure OC4J to validate XML files, add the -validateXML
option to the command line used in the OC4J start up script (<
OC4J_HOME
>/BIN/oc4j.cmd
or oc4j
).
Example 31-3 shows how to set this option in the oc4j.cmd
file.
Example 31-3 Setting -validateXML in oc4j.cmd
... "%JAVA_HOME%\bin\java" %JVMARGS% -jar %OC4J_JAR% %CMDARGS% -validateXML ...
With this option set, OC4J strictly validates XML files against their specified schema when OC4J reads them. OC4J logs any errors (see "Configuring EJB Logging").
You can configure OC4J to write out the ejb-jar.xml
file it creates based on your EJB 3.0 annotations (see "Troubleshooting Application Deployment").
See also "Validating XML Files".
By default, when OC4J deploys an application, it generates wrapper code in <OC4J_HOME>/j2ee/home/application-deployments/<ear-name>/<ejb-name>/generated
, compiles it, 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.
This section describes:
If you set system property KeepWrapperCode
to true
, OC4J preserves the wrapper code it generates in the default directory <OC4J_HOME>/j2ee/home/application-deployments/<ear-name>/<ejb-name>/generated
.
If you undeploy your application, OC4J deletes the wrapper code in this directory.
If you set both system property KeepWrapperCode
to true
and system property WrapperCodeDir
to a directory (call it <specified-wrapper-dir>
), OC4J generates wrapper code to this directory and preserves the wrapper code even if you undeploy the application.
The <specified-wrapper-dir>
may be absolute (such as C:\wrappers
) or relative (such as ./wrappers
): relative paths are relative to <OC4J_HOME>/j2ee/home
.
If OC4J cannot generate to the directory you specify (for example, due to a permission problem or lack of space), OC4J generates wrapper code to the default directory <OC4J_HOME>/j2ee/home/application-deployments/<ear-name>/<ejb-name>/generated
and preserves this wrapper code even if you undeploy the application.
If you set system property KeepWrapperCode
to false
(or leave this system property unset), OC4J will not preserve the wrapper code it generates.