This chapter explains how to configure the Java EE containers included in the server. This chapter contains following sections:
This section describes the Java EE containers included with the Application Server.
Java EE containers provide runtime support for Java EE application components. Java EE application components use the protocols and methods of the container to access other application components and services provided by the server. The Application Server provides an application client container, an applet container, a Web container, and an EJB container. For a diagram that shows the containers, see the section Application Server Architecture.
The Web Container is a Java EE container that hosts web applications. The web container extends the web server functionality by providing developers the environment to run servlets and JavaServer Pages (JSP files).
Enterprise beans (EJB components) are Java programming language server components that contain business logic. The EJB container provides local and remote access to enterprise beans.
There are three types of enterprise beans: session beans, entity beans, and message-driven beans. Session beans represent transient objects and processes and typically are used by a single client. Entity beans represent persistent data, typically maintained in a database. Message-driven beans are used to pass messages asynchronously to application modules and services.
The container is responsible for creating the enterprise bean, binding the enterprise bean to the naming service so other application components can access the enterprise bean, ensuring only authorized clients have access to the enterprise bean’s methods, saving the bean’s state to persistent storage, caching the state of the bean, and activating or passivating the bean when necessary.
Sun Java System Application Server 9 conforms to Java EE 5 and EJB 3.0 specifications Therefore a JNDI name will be no longer be required for EJB 3.0 session beans that expose a Remote view. If a deployed Remote EJB 3.0 bean does not provide a global JNDI name, the container will assign it one at runtime. The assigned JNDI name is the fully qualified class name of the remote EJB's business interface. In addition, EJB clients that use the new Remote EJB 3.0 client view will not be required to map their remote @EJB references to a global JNDI name within sun-ejb-jar.xml. If a JNDI name has not been associated with the ejb reference, the container will derive the default JNDI name for the target EJB from its associated business interface.
Applications using this EJB 3.0 feature will no longer need sun-ejb-jar.xml or sun-application-client.xml configuration files. The older method of providing a JNDI name in sun-ejb-jar.xml will continue to work. It will also be possible for the application to map an ejb-reference or @EJB reference to a specific global JNDI name.
See Also:
This section describes the HTTP session settings in the Web container. HTTP sessions are unique web sessions that have their state data written to a persistent store.
Use the Admin Console to set the HTTP session timeout value. The session timeout value represents the duration for which an HTTP session is valid.
In the Admin Console, go to Configuration> Web Container > Session Properties. In the Session Timeout field, enter the number of seconds that a session is valid.
For detailed instructions on setting the session timeout value, Click Help in the Admin Console.
The session manager provides the means to configure how sessions are created and destroyed, where session state is stored, and the maximum number of sessions.
To change the session manager settings in the Admin Console, go to Configuration> Web Container > Manager Properties.
In the Manager Properties tab, set the following properties:
Reap Interval value. The Reap Interval field is the number of seconds before the inactive session data is deleted from the store.
Max Sessions value. The Max Sessions field is the maximum number of sessions allowed.
Set the Session Filename value. The Session Filename field is the file that contains the session data.
Session ID Generator Classname value.
The Session ID Generator Classname field allows you to specify a custom class for generating unique session IDs. Only one session ID generator class per server instance is permitted, and all instances in a cluster must use the same session ID generator to prevent session key collision.
Custom session ID generator classes must implement the com.sun.enterprise.util.uuid.UuidGenerator interface:
package com.sun.enterprise.util.uuid; public interface UuidGenerator { public String generateUuid(); public String generateUuid(Object obj); //obj is the session object }
The class must be in the Application Server classpath.
For detailed instructions on setting the manager properties, Click Help in the Admin Console.
To specify where the session store data will be saved, in the Admin Console, go to Configuration > Web Container > Store Properties.
Set the Reap Interval field
The Reap Interval field is the number of seconds before the inactive session data is deleted from the store.
Specify the directory where session data will be stored.
For detailed instructions on setting the session store properties, Click Help in the Admin Console.
By default, the web container returns an HTTP response header with an attribute whose name is "Server" and value is the version of the Application Server Software. For example, on Application Server 9 Platform Edition, the value is: "Server: Sun Java System Application Server Enterprise Edition 9.0 FCS". Run the asadmin version command to view the version of your installation. If you want to override this value, define a Java Property named product.name in the server's configuration and initialize it to the value of your choice. This value determines what is returned by the server in the HTTP response. To change the property:
Start the Application Server and log in to Admin Console.
Click Application Server and click the JVM Settings tab.
Click Add JVM Option.
Enter the following value: -Dproduct.name="My Name".
The following section describes settings that apply to all enterprise bean containers on the server:
To override the defaults on a per-container basis, adjust the values in the enterprise bean’s sun-ejb-jar.xml file. For details, see the Sun Java System Application Server Platform Edition 9 Developer’s Guide.
The Session Store Location field specifies the directory where passivated beans and persisted HTTP sessions are stored on the file system.
Passivated beans are enterprise beans that have had their state written to a file on the file system. Passivated beans typically have been idle for a certain period of time, and are not currently being accessed by clients.
Similar to passivated beans, persisted HTTP sessions are individual web sessions that have had their state written to a file on the file system.
The Commit Option field specifies how the container caches passivated entity bean instances between transactions.
Option B caches entity bean instances between transactions, and is selected by default. Option C disables caching.
The container maintains a pool of enterprise beans in order to respond to client requests without the performance hit that results from creating the beans. These settings only apply to stateless session beans and entity beans.
If you experience performance problems in an application that uses deployed enterprise beans, creating a pool, or increasing the number of beans maintained by an existing pool, can help increase the application’s performance.
By default, the container maintains a pool of enterprise beans.
To set the EJB pool properties using the Admin Console, go to Configuration > EJB Container > EJB Settings.
Under Pool Settings in the Initial and Minimum Pool Size field enter the minimum number of beans the container creates in the pool.
In the Maximum Pool Size field enter the maximum number of beans the container maintains in the pool, at any time.
In the Pool Resize Quantity field enter the number of beans that will be removed from the pool if they are idle for more than the time specified in Pool Idle Timeout.
In the Pool Idle Timeout field enter the time, in seconds, that a bean in the pool can remain idle before it will be removed from the pool.
Restart the Application Server.
For detailed instructions on configuring the EJB pool, Click Help in the Admin Console.
The container maintains a cache of enterprise bean data for the most used enterprise beans. This allows the container to respond more quickly to requests from other application modules for data from the enterprise beans. This section applies only to stateful session beans and entity beans.
Cached enterprise beans are in one of three states: active, idle, or passivated. An active enterprise bean is currently being accessed by clients. An idle enterprise bean’s data is currently in the cache, but no clients are accessing the bean. A passivated bean’s data is temporarily stored, and read back into the cache if a client requests the bean.
To configure the EJB cache settings using the Admin Console, go to Configuration > EJB Container > EJB Settings.
Adjust the maximum cache size in the Max Cache Size field.
Increase the maximum number of beans to cache to eliminate the overhead of bean creation and destruction. However, if the cache is increased, the server consumes more memory and resources. Be sure your operating environment is sufficient for your cache settings.
Adjust the cache resize quantity in the Cache Resize Quantity field.
When the maximum number of cached beans is reached, the container removes a number of passivated beans from the backup store, set to 32 by default.
Adjust the rate, in seconds, at which the cache cleanup is scheduled for entity beans in the Cache Idle Timeout field.
If a cached entity bean has been idle a certain amount of time, it is passivated. That is, the bean’s state is written to a backup store.
Adjust the time, in seconds, after which stateful session beans are removed from the cache or passivated store in the Removal Timeout field.
Configure the policy the container uses to remove stateful session beans in the Removal Selection Policy field.
The container decides which stateful session beans to remove based on the policy set in the Removal Selection Policy field. There are three possible policies the container uses to remove beans from the cache:
Not recently used (NRU)
First in, first out (FIFO)
Least recently used (LRU)
The NRU policy removes a bean that hasn’t been used recently. The FIFO policy removes the oldest bean in the cache. The LRU policy removes the least recently accessed bean. By default, the NRU policy is used by the container.
Entity beans are always removed using the FIFO policy.
Restart the Application Server.
For detailed instructions on configuring the EJB pool, Click Help in the Admin Console.
The pool for message-driven beans is similar to the pool for session beans described in Configuring EJB Pool Settings. By default, the container maintains a pool of message-driven beans.
To adjust the configuration of this pool using the Admin Console, go to Configuration > EJB Container > MDB Settings.
Under Pool Settings in the Initial and Minimum Pool Size field, enter the minimum number of message beans the container creates in the pool.
In the Maximum Pool Size field, enter the maximum number of beans the container maintains in the pool, at any time.
In the Pool Resize Quantity field, enter the number of beans that are removed from the pool if they are idle for more than the time specified in Pool Idle Timeout.
In the Pool Idle Timeout field, enter the time, in seconds, that a bean in the pool can remain idle before it is removed from the pool.
Restart the Application Server.
For detailed instructions on configuring the MDB settings, Click Help in the Admin Console.
The timer service is a persistent and transactional notification service provided by the enterprise bean container used to schedule notifications or events used by enterprise beans. All enterprise beans except stateful session beans can receive notifications from the timer service. Timers set by the service are not destroyed when the server is shut down or restarted.
To configure the EJB Timer Service using the Admin Console, go to Configuration > EJB Container > EJB Timer Service.
Set the minimum delivery interval in milliseconds in the Minimum Delivery Interval field.
Minimum Delivery Interval is the minimum number of milliseconds allowed before the next timer expiration for a particular timer can occur. Setting this interval too low can cause server overload.
Set the maximum number of attempts the timer service makes to deliver the notification in the Maximum Redeliveries field.
Set the interval, in milliseconds, between redelivery attempts in the Redelivery Interval field.
Specify the JNDI name of the JDBC resource that will be used as the Timer Datasource.
Restart the Application Server.
By default, the timer service uses an embedded database to store timers. You can set up the timer service to another database.
Sample timer database creation files are provided for Java DB (Derby), PointBase, Oracle, Sybase, DB2, and MS SQL Server at install-dir/lib/install/databases/.
To use an external database with the Timer Service, first, set up a JDBC resource for the selected database as described in Creating a JDBC Resource. Then go to Configuration > EJB Container > EJB Timer Service and enter the JNDI name of the resource in the Timer DataSource field. Restart the Application Server.
See the following for related information: