Skip Headers
Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide
10g Release 3 (10.1.3)
B14428-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
 
Next
Next
 

31 Administrating an EJB Application

This chapter describes:

For more information, see "Understanding EJB Administration".

OC4J EJB JMX Support

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").

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:

  1. Launch Application Server Control.

  2. Click the Administration link.

  3. Click System MBean Browser.

  4. 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

  5. Select the type of EJB, such as StatelessSessionBean, MessageDrivenBean, or WebServicePort.

  6. Select an MBean instance.

  7. 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:

Configuring EJB Logging

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:

Logging Namespaces

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

Logging Levels

You can configure log levels of: FINER, FINE, CONFIG, INFO, WARNING, and SEVERE.

Configuring Logging with Application Server Control Logging MBean

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.

Configuring Logging Using the j2ee-logging.xml File

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:

Configuring Logging Using System Properties

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.

Example 31-2 Configuring a Logger with a System Property

oracle.j2ee.logging.finest=oracle.j2ee.ejb.deployment

Managing the Bean Instance Pool

OC4J provides EJB pooling attributes that you can configure to improve performance by reducing the frequency of bean instance creation.

This section describes:

Configuring Bean Instance Pool Size

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:

Using Deployment XML

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").

Configuring Bean Instance Pool Timeouts for Session Beans

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:

Using Deployment XML

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").

Configuring Bean Instance Pool Timeouts for Entity Beans

You can set the maximum amount of time that entities are cached in the bean instance pool.

You can configure pool timeouts for entities:

Using Deployment XML

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").

Starting and Stopping an EJB Application

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

Troubleshooting an EJB Application

This section describes:

Validating XML Files

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").

Debugging the ejb-jar.xml File

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

Debugging Generated Code

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:

Preserving Generated Code in the Default Directory

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.

Preserving Generated Code in a Directory You Specify

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.

Disabling Generated Code Preservation

If you set system property KeepWrapperCode to false (or leave this system property unset), OC4J will not preserve the wrapper code it generates.