No stateful session EJB instances exist in WebLogic Server at startup. Before a client begins accessing a stateful session bean, it creates a new bean instance to use during its session with the bean. When the session is over the instance is destroyed. While the session is in progress, the instance is cached in memory.

Passivation is the process by which WebLogic Server removes an EJB instance from cache while preserving its state on disk. While passivated, EJBs are not in memory and are not immediately available for client requests, as they are when in the cache.

The EJB developer must ensure that a call to the ejbPassivate() method leaves a stateful session bean in a condition such that WebLogic Server can serialize its data and passivate the instance. During passivation, WebLogic Server attempts to serialize any fields that are not declared transient. This means that you must ensure that all non-transient fields represent serializable objects, such as the bean's remote or home interface. EJB 2.1 specifies the field types that are allowed.

The rules that govern the passivation of stateful session beans vary, based on the value of the beans cache-type element, which can be:

• LRU—least recently used, or eager passivation.

• NRU—not recently used, or as lazy passivation

The idle-timeout-seconds and max-beans-in-cache elements also affect passivation and removal behaviors, based on the value of cache-type.

• Eager Passivation (LRU)
  
• Lazy Passivation (NRU)
  

When a stateful session bean is passivated, its state is stored in a file system directory. Each server instance has its own directory for storing the state of passivated stateful session beans, known as the persistent store directory. The persistent store directory contains one subdirectory for each passivated bean.

The persistent store directory is created by default in the server instance directory, for example:

D:\releases\<version>\bea\user_domains\mydomain\myserver\tmp\pstore\

The path to the persistence store is:

RootDirectory\ServerName\persistent-store-dir

where:

• RootDirectory—the directory where WebLogic Server runs.

  RootDirectory can be specified at server startup with the -Dweblogic.RootDirectory property.

• ServerName—the name of the server instance.

• persistent-store-dir—the value of the of the persistent-store-dir element in the <stateful-session-descriptor> element of weblogic-ejb-jar.xml. If no value is specified for <persistent-store-dir>, the directory is named pstore by default.

The persistent store directory contains a subdirectory, named with a hash code, for each passivated bean. For example, the subdirectory for a passivated bean in the example above might be:

D:\releases\810\bea\user_domains\mydomain\myserver\pstore\14t89gex0m2fr

In accordance with the EJB 2.x specification, simultaneous access to a stateful session EJB results in a RemoteException. This access restriction on stateful session EJBs applies whether the EJB client is remote or internal to WebLogic Server. To override this restriction and configure a stateful session bean to allow concurrent calls, set the allow-concurrent-calls deployment element.

If multiple servlet classes access a stateful session EJB, each servlet thread (rather than each instance of the servlet class) must have its own session EJB instance. To prevent concurrent access, a JSP/servlet can use a stateful session bean in request scope.

Stateless session beans are a good choice if your application does not need to maintain state for a particular client between business method calls. WebLogic Server is multi-threaded, servicing multiple clients simultaneously. With stateless session beans, the EJB container is free to use any available, pooled bean instance to service a client request, rather than reserving an instance for each client for the duration of a session. This results in greater resource utilization, scalability and throughput.

Stateless session beans are preferred for their light-weight implementation. They are a good choice if your application's beans perform autonomous, distinct tasks without bean-to-bean interaction.

Stateful session beans are a good choice if you need to preserve the bean's state for the duration of the session.

For examples of applications of stateless and stateful session beans, see Stateless Session Beans and Stateful Session Beans.

When you choose values for initial-beans-in-free-pool and max-beans-in-free-pool you must weigh memory consumption against slowing down your application. If the number of stateless session bean instances is too high, the free pool contains inactive instances that consume memory. If the number is too low, a client may not obtain an instance when it needs it. This leads to client threads blocking until an instance frees up, slowing down the application.

Usually max-beans-in-free-pool should be equal to the number of worker threads in the server instance, so that when a thread tries to do work an instance is available.