8.3.5 Controlling the number of concurrently executed threads in a Enterprise Bean

(1) Types of functions that can be used for concurrently executed thread control of Enterprise Bean

The following two types of functions of the EJB container are used for controlling the concurrently executed threads of Enterprise Bean:

Instance Pooling

Instance pooling is a function that creates an instance of Enterprise Bean in advance and immediately processes the requests sent by the client. You can queue the execution of requests that exceed the upper limit by setting the maximum number of instances to be pooled. This helps in controlling the number of concurrently executed threads.

Reference note

When dynamically changing the number of concurrent executions of CTM during operation, you must set up no upper limit to the upper-limit value.

Session control

Session control is a function for controlling the number of sessions (instances) that is concurrently generated in the session.

The functions that can be used differ based on the type of Enterprise Bean.

The following table describes the functions of concurrently executed thread control that can be used based on the type of Enterprise Bean:

Table 8‒4: Functions of concurrently executed thread control that can be used based on the type of Enterprise Bean

Type of Enterprise Bean	Control function that can be used
Stateless Session Bean#	Instance pooling
Stateful Session Bean	Session control
Entity Bean	Instance pooling and session control
Message-driven Bean	Instance pooling

Among the concurrently executed thread controls of Enterprise Bean, Message-driven Bean is the only one that manages the requests using the concept of queue for controlling the pending requests. In the case of Message-driven Bean, pending requests are controlled by using a JMS queue. In other Enterprise Beans, when a request sent from the client exceeds the maximum number of concurrent executions one of the following processes is performed, according to the setup:

• Request is kept in a queue until there is a free instance

• Immediately returned as an exception to the client

• Return the request as an exception to the client after timeout that is set for acquiring instance (in the case of method-ready pool or Entity Bean pool of the Stateless Session Bean)

To Page Top

(2) Controlling the number of concurrent executions in a Stateless Session Bean

Instance pooling can be used in the Stateless Session Bean. Set the normal simultaneous access count as the minimum value of instance pooling, and specify the value exceeding the maximum number of the expected simultaneous access count for the maximum value of instance pooling. This will save the time required for generating an instance during normal access and enhance the processing efficiency. Further, even when the access count increases, the access requests can be processed until it reaches the expected number of maximum access count and the execution of any request that exceeds the maximum access count is held in the pending queue.

By default, a request that exceeds the upper limit is not returned as an error. It remains in the queue until the pooled instance becomes empty. To return the request as an error, set the timeout for instance collection queue if required.

To Page Top

(3) Controlling the number of concurrent executions in a Stateful Session Bean

As the Stateful Session Bean has a state for each session for each client, the number of concurrent executions cannot be controlled accurately. Stateful Session Bean enables flow control (session control) in the session.

Specify the maximum expected concurrently executed sessions as the maximum value of session control. When the number of access requests increase and there is an access request that exceeds the maximum expected concurrently executed sessions, the session is not established and it is returned as an exception (java.rmi.RemoteException) to the client.

Tip

When it is necessary to control the number of concurrent executions of each request, it is possible to control the number of concurrent executions of Web application or control the number of concurrent executions using instance pooling, by invoking Stateful Session Bean through servlet, JSP or Stateless Session Bean.

To Page Top

(4) Controlling the number of concurrent executions in an Entity Bean

In the case of an Entity Bean, the number of concurrent executions can be controlled through the setup of maximum sessions that can be controlled for each client, and instance pooling. When maximum number of sessions is reached, request for a new session cannot be executed even if there is a vacancy in the instance pool.

When the maximum number of sessions is exceeded, an exception (java.rmi.RemoteException) is notified to the client immediately when there is a failure to generate the session. In the case of default settings, a request that exceeds the maximum number of instance pools is not returned as an error but kept pending in queue until there is a vacancy in the pooled instances. To return the request as an error, specify a timeout for instance collection queue as required.

The database is accessed in the execution of request for the Entity Bean. The number of connections for accessing the database also controls the number of requests that can be executed concurrently.

To Page Top

(5) Controlling the number of concurrent executions in a Message-driven Bean

You can use instance pooling in a Message-driven Bean. Specify the value of maximum messages as the maximum value of instance pooling. This helps to save the time required to generate an instance when a message arrives and enhance the processing performance. Even when the number of messages increases, keeping the messages pending in a queue can control the execution of the messages exceeding the maximum value for instance pooling.

In the case of Message-driven Bean, the incoming messages can be managed in the pending queue by using a JMS queue.

Reference note

When invoking Message-driven Bean from SUP of OpenTP1 using the TP1 inbound integrated function or when invoking Message-driven Bean using Cosminexus JMS provider, you must examine the number of concurrent executions in view of the component used along with the contents described in this section. For details, see 4. Invoking Application Server from OpenTP1 (TP1 inbound integrated function) or 6. Cosminexus JMS Provider in the uCosminexus Application Server Common Container Functionality Guide.

To Page Top