Configuring the EJB components

Now that we have shortly resumed the basic types of EJB, we will enter in the specific details of the application server configuration. We will therefore examine the following components:

• The SLSB configuration
• The SFSB configuration
• The MDB configuration
• The Timer service configuration

Let’s see them all in detail:

Configuring Stateless Session Beans

By default, no Stateless Session Bean instances exist in JBoss AS at start-up time. As individual beans are invoked, the EJB container initializes new SLSB instances.

These instances are maintained in a free pool, which will be used to service EJB method calls. The EJB remains active for the duration of the client’s method call. After the method completes, the EJB instance is returned to the free pool. Because the EJB container unbinds Stateless Session Beans from clients after each method call, the actual bean class instance that a client uses may be different from invocation to invocation.

If all instances of an EJB class are active and the pool’s max-pool-size has been reached, new clients requesting the EJB class will be blocked until an active EJB

completes a method call. Depending on how you have configured your stateless pool, an acquisition timeout can be triggered, if you are not able to acquire an instance from the pool within a maximum time.

You can either configure your Session Pool through your main configuration file or programmatically. Let’s see both approaches:

EJB are part of the ejb3.1.2 subsystems; in order to configure your pool, you can operate on two parameters: the maximum size of the pool (max-pool-size)and the instance acquisition timeout (instance-acquisition-timeout). Let’s see an example:

In this example, we have configured the SLSB pool with a strict upper limit of 25 elements. The strict pool implementation is the only available at the time of writing, and it allows a fixed number of concurrent requests to run at one time. If there are more requests running than the pool’s strict size, those requests will block until an instance becomes available. Within the pool configuration, we have also set an instance-acquisition-timeout of 5 minutes, which will come into play if your requests are larger than the pool size.

You can configure as many pools as you like; the pool which will be used by the EJB container is indicated by the attribute pool-name of the bean-instance-pool-ref element. For example, here we have added one more pool configuration named largepool, and set it as the EJB container’s pool implementation:

Using the CLI to configure the Stateless pool size

We have detailed the steps necessary to configure the SLSB pool size, through the main configuration file. However, the suggested best practice is to use the Command Line

Using the CLI to configure the Stateless pool size We have detailed the steps necessary to configure the SLSB pool size, through the main configuration file. However, the suggested best practice is to use the Command Line Interface to alter the server model.

Here’s how you can add a new pool named large-pool to your EJB 3 sub-system: /subsystem=ejb3/strict-max-bean-instance-pool=large-pool:add(max-pool-size=100)

Frequently asked Jboss Interview Questions

Now you can set this pool as the default used by the EJB container: /subsystem=ejb3:write-attribute(name=default-slsb-instance-pool, value=large-pool)

Finally, you can, at any time, change the pool size property by operating on the max-pool-size attribute:

/subsystem=ejb3/strict-max-bean-instance-pool=large-pool:write-attribute(name=”max-pool-size”,value=50)

Configuring Stateful session beans

SFSB are bound to particular client instances: the application server uses a cache to store active EJB instances in memory, so that they are immediately available for client requests. The cache contains EJBs that are currently in use by a client and instances that were recently in use.

Having EJBs in memory is a costly operation, so you should move as soon as possible out of it, either by passivating them or removing them.

Passivation is a process by which the EJB container ensures that idle SFSB instances are freed from the cache, but save their state on disk.

Removing a bean from the cache, on the other hand, is a process, which can be either triggered by the user or by the EJB container. When triggered by the user, it is accomplished by adding a @javax.ejb.Remove annotation on a method of your EJBs, which will actually remove the EJB when invoked:

@Remove

public void remove() {}

At the moment, the configuration tweaks available for the stateful session beans include just the access timeout for the stateful instances.

However, thanks to the help of the JBoss Team, and in particular of Paul Ferraro, we are able to share a preview of the Stateful cache configuration in AS 7 future releases. Cache definitions in AS 7.1 will be defined within the ejb3.1 subsystem. Within the definition of a cache, you’ll have the option to specify a passivation store, which can optionally define a max-size.

As you can see, the stateful bean element references a cache definition, which in turn is connected with a passivation-store. In this configuration example, the file-based passivating cache is used for non-clustered SFSBs. Notice the optional max-size attribute which limits the amount of SFSB which can be contained in the cache. On the other hand, the clustered cache is backed by infinispan’s cluster-passivation-store. (See Chapter 8 for more information about Infinispan Cache).