The methods of controlling the number of concurrently executed threads in an Enterprise Bean are explained below for each type of Enterprise Bean. The functions of an EJB container are used to implement the concurrently executed thread control of Enterprise Bean by instance pooling and session control. For details about the functions of EJB container, see 2. EJB Container in the uCosminexus Application Server EJB Container Functionality Guide.
The following two types of functions of the EJB container are used for controlling the concurrently executed threads of Enterprise Bean:
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-5 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:
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.
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.
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.
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.