Table of Contents
This chapter describes stateless session beans and stateful session beans in detail.
The stateless session bean requires no additional configurations other than the ones that were already explained in "Chapter 4. Common Characteristics of EJB". Therefore, this chapter will mainly talk about stateful session beans.
This section describes about the Thread Ticket Pool (hereafter TTP) of session beans.
Stateless session bean does not need to specify a connection pool because it does not have state information related to client requests and all clients share connections. However, because it is stateless and can reuse bean instances, it can use a bean pool.
The following figure shows the relationship of TTP to a bean pool of a stateless session bean.
-
If TTP receives a request from a connection to a client at the time of creation, it obtains a Thread Ticket. If TTP cannot obtain the TT, it will wait until it receives the TT as described in "Chapter 4. Common Characteristics of EJB". If the wait time exceeds 10 minutes, RemoteException will occur and the request cannot be performed.
-
TTP gets an actual bean instance from the bean pool and makes a connection to handle the request.
-
When a stateless session bean instance completes handling the request, the TT is returned to TTP and the bean instance is returned to the bean pool, and waits for the next request. For each request, a TT and a bean instance is allocated and returned.
The size of a bean pool differs from the size of TTP in that it is related to the number of local and remote client requests that can be simultaneously handled. For a remote call, TT is obtained from TTP and then an instance can be obtained from the bean pool. For a local call, since it is performed directly by a client thread, there is no need for a TT and only an instance is obtained from the bean pool.
Therefore, while the number of remote calls that can be handled cannot exceed the value of <thread-max> in jeus-ejb-dd.xml, any number of local calls can be handled because the maximum bean pool size is unlimited.
From EJB 2.1, a stateless session bean can be exported in the form of a web service.
Note
For more information on this, refer to "JEUS Web Service Guide".
This section describes additional configurations for stateful session beans.
-
Object management configuration: the bean instance pool and the connection pool
-
Bean instance pooling option
-
State persistence mechanisms through session manager
Since a stateful session bean needs to persistently store state information between client requests, we need to configure and utilize a connection pool (hereafter CP). The same also applies to entity beans. For more information, refer to "Chapter 8. Entity Bean".
The following figure shows the relationship between a bean pool, connection pool, and TTP of a stateful session bean.
If a client creates a stateful session bean, a new bean instance (SF instance) is created and a connection is made between the two through the Connection Pool. If the connection to the bean instance is given to a client, the connection is allocated only to the current client and is not shared with other clients. Therefore, unless the client discards it, it will not be returned to the Connection Pool. When it is returned to the Connection Pool, the connection also gets disconnected from the bean instance.
If a request is sent through the relevant connection, a TT is sent from the TTP. Only the requests that have received a TT are handled. Unlike stateless session beans, a bean instance is not allocated from a bean pool for each request, but a bean instance is assigned for a specific client.
As already mentioned, the bean instance is deleted when it is disconnected because the connection is returned to the Connection Pool when a client discards a bean. Since a stateful session bean contains state information, a bean pool that reuses a bean instance is not used.
According to the J2EE EJB specification, the actual instance of a stateful session bean may not be reused by different client sessions. It appears that this requirement, in most cases, is not really useful. JEUS therefore offers a way to go around the specification in this respect to achieve higher performance and reduce resource waste.
If a bean pool is used, the bean pool instance is returned to the bean pool when the bean is deleted. A bean is deleted when a client calls remove() or a timeout occurs. At that time, PRE DESTROY callback is invoked, but this is only recommended when the initialization of the bean has been well implemented.
To turn a stateful session bean into a bean that is pooled, you simply set the <pooling-bean> element in jeusejb- dd.xml to "true" as follows:
[Example 7.1] Bean Pool Configuration: <<jeus-ejb-dd.xml>>
<jeus-ejb-dd>
. . .
<beanlist>
<jeus-bean>
<ejb-name>teller</ejb-name>
<export-name>TELLEREJB</export-name>
<local-export-name>LOCALTELLEREJB</local-export-name>
<export-port>7654</export-port>
<export-iiop>true</export-iiop>
<object-management>
<pooling-bean>true</pooling-bean>
<bean-pool>
<pool-min>10</pool-min>
<pool-max>200</pool-max>
<resizing-period>1800000</resizing-period>
</bean-pool>
. . .
</object-management>
. . .
</jeus-bean>
. . .
</beanlist>
. . .
</jeus-ejb-dd>
As the name clearly implies, a stateful session bean contains state information. This information must be kept during a client session (i.e., the state must be preserved over a number of separate client requests coming from the same client). This is the basic property of stateful session beans.
Normally, during runtime, the state is naturally stored as a set of instance variables. However, after the stateful session bean enters the inactivated state as previously described, we need to remove these instance variables from the runtime environment in order to preserve system resources. This is why we need a secondary storage to where we can safely write the variables (state) to be retrieved later into memory when the bean is re-activated.
The distributed session manager included in JEUS is used as the secondary storage. Normally, when the bean is passivated, clustered stateful session bean information is sent to the session manager for failover when the bean successfully commits the transaction. The session manager is configured in DAS.
For more information, refer to "6.3.3. Clustering Configuration for Stateful Session Bean".
This section describes commonly used configuration for stateless and stateful session beans. The configuration is specified in the <jeus-bean> element of the JEUS EJB module DD.
Since stateless session beans do not have state information and a single connection can be used, they can just use the bean pool. However, since stateful session beans have state information, they can use both a connection pool and a bean pool. Therefore, the following settings can be configured for a pool to reduce the load of creating a new instance each time.
The following is an example of XML section related to object management configuration.
[Example 7.2] Object Management Configuration: <<jeus-ejb-dd.xml>>
<jeus-ejb-dd>
. . .
<beanlist>
<jeus-bean>
. . .
<object-management>
<bean-pool>
<pool-min>10</pool-min>
<pool-max>200</pool-max>
</bean-pool>
<connect-pool>
<pool-min>10</pool-min>
<pool-max>200</pool-max>
</connect-pool>
<passivation-timeout>10000</passivation-timeout>
<disconnect-timeout>1800000</disconnect-timeout>
</object-management>
<jeus-bean>
. . .
<beanlist>
. . .
<jeus-ejb-dd>
Details for sub elements of the <object-management> element.
-
-
Determines the behavior of the bean instance pool.
-
Sub-elements are:
-
Element Description <pool-min> Initial number of bean instances created when a pool is initialized (default value: 0). <pool-max> Maximum number of bean instances that can be stored a pool after use. (default value: 100).
<resizing-period> Time interval for resizing a pool. Resizing means that unused bean instances are removed keeping only the minimum number of bean instances. (default value: 15 minutes, Unit: ms)
-
-
-
Determines the number of connections, that connect clients and bean instances, to keep (From JEUS 6.0 Fix8, this option is not used for session beans).
-
Sub-elements are:
Element Description <pool-min> Initial number of connections created when a pool is initialized (default value: 0). <pool-max> Maximum number of connections for a pool after the connection is used. (default value: 100).
<resizing-period> Time interval for resizing a pool. Resizing means that unused bean instances are removed keeping only the minimum number of bean instances. (default value: 15 minutes, Unit: ms)
-
-
-
Used for inactivating a bean in the EJB engine for which there are no client request for a specified period of time. If a bean receives no client requests during the specified time period set in this element, the bean is subject to passivation.
The time interval for checking passivation targets depends on the <resolution> value in EJBMain.xml. The relevant bean instance is deleted from memory, the state of the instance is saved to a file using a distributed session server internally.
-
These settings can be configured at several locations and their priorities are as follows:
-
Applied to only certain session bean: <passivation-timeout> of jeus-ejb-dd.xml.
-
Applied to all stateful session beans: the system property jeus.ejb.stateful.passivate
-
Applied to all EJB beans (all entity beans and session beans): the system property jeus.ejb.all.passivate
-
Applied to all EJB beans (all entity beans and session beans): <node>/<session-router-config>/<session- router>/<file-db>/<passivation-to> of DAS
If all of these settings do not exist, default is set to 300,000ms (5 minutes).
-
-
-
-
Used for disconnecting a connection between the client and a stateful session bean instance if no client request is received during the amount of time specified here. This means that the connections are disconnected from each client and instance, and returned to a connection pool.
Therefore, a client cannot make a request through this connection anymore, and bean instances in use are removed, or returned to a bean pool if a bean pool is used.
-
These settings can be configured at several locations and their priorities are as follows:
-
Applied to only certain session bean: <disconnect-timeout> of jeus-ejb-dd.xml
-
Applied to all stateful session beans: the system property jeus.ejb.stateful.disconnect
-
Applied to all EJB beans (all entity beans and session beans): the system property jeus.ejb.all.disconnect
If all of these settings do not exist, default is set to 3,600,000ms (1hour), the default value of system property jeus.ejb.all.disconnect.
-
Note
The time period used for <passivation-timeout> and <disconnect-timeout> are both measured from the time of the last access of the bean instance. This means that you should set the <disconnect-timeout> period considerably larger than <passivation-timeout>. And <passivation-timeout> should be larger than the resolution value specified in the EJB engine.
If timeout value is too large (more than 10 minutes or when timeout is stopped), a large number of inactivated instances remain in the memory for the long duration, wasting system resources. Too short of a timeout period (several seconds), however, may undermine the performance due to frequent inactivations and activations, and has a risk of losing the session values.
-