In this release, there are no container-wide settings for the Web container in the Administration Console.
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 Administration Console to set the HTTP session timeout value. The session timeout value represents the duration for which an HTTP session is valid.
In the Administration 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 Administration 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 Administration Console, go to Configuration > Web Container > Manager Properties.
Select the instance to configure:
To configure a particular instance, select the instance’s config node. For example, the default instance, server, select the server-config node.
To configure the default settings for all instances, select the default-config node.
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 Administration Console.
To specify where the session store data will be saved, in the Administration Console, go to Configuration > Web Container > Store Properties.
Select the instance to configure:
To configure a particular instance, select the instance’s config node. For example, the default instance, server, select the server-config node.
To configure the default settings for all instances, select the default-config node.
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 Administration Console.
When you install Application Server, a default virtual server for the Application Server instance is created. The default docroot for this virtual server is created at instance-dirdomains/domain1/docroot, which is synchronized to the instance_name/docroot. A virtual server is created for each additional Application Server instance you create.
This section describes the following settings, which 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 Application Server 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.
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.
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:
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.