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.

[Figure 7.1] TTP and Bean Pool of Stateless Session Bean

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.

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

The following figure shows the relationship among a bean pool, connection pool, and TTP of a stateful session bean.

[Figure 7.2] Connection Pool, Thread Ticket Pool, and Bean Pool 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 among 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:

<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. Configuring the Stateful Session Bean Clustering".

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.

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