JBossDeveloper

I repeat the bean ageing does not apply to
stateless only to stateful.

Stateless beans do not have a cache, all
stateless beans are equivalent in a pool.

Storing a reference to a stateful bean in a
stateless bean breaks that contract unless they
all reference the same stateful bean instance.
But this then breaks the single threading
requirement of stateful beans unless you configure
your stateless pool to have a strict size of 1.

Regards,
Adrian

Stateless beans of the same type are kept in a single pool. They are stateless, meaning that if I grabbed one and used that bean, it would react no differently to doing the same with another one I randomly grabbed from the pool. As I finish with a stateless session bean, it gets released back to the pool. Next time I grab another bean from this pool, it might be the same bean or it might be another.

Stateless session beans are only destroyed if you shut down the container, or as a result of the pool shrinking as demand shrinks. You often do not want your pool to shrink to zero - it is costly to create a new bean, so for much the same reason that you have connection pools because connections are costly to create so we have stateless session beans. We want enough stateless session beans pre-created and available in the pool to service standard load for the application.

Every request for a stateless session bean does not necessarily mean that a stateless session bean is created. The container decides whether there is a bean available for the request, and if there is not, and the maximum number of those beans allowed has not been reached, it will create one. Otherwise, the container will just give you one of the beans already existing in the pool, because no bean is different to another.

The rate of decay is not required to be defined in containers for a stateless session pool, like the rate of decay for a connection pool - e.g How quickly the pool shrinks. Nor are there any definitions for the basis of disposal - it could be LRU, it could be round-robin; the algorithm chosen may be the one most resource efficient for the architecture.

You have modified things. Each stateless bean is different as it is attached to a different or unique stateful session bean. This one to one binding makes each stateless session bean unique in terms of the method use - it is dependent on an underlying service that is not guaranteed to exist for the lifetime of the container. Essentially, you have violated the non-uniqueness criteria for the use of stateless session beans with this dependency.

This is your test for a stateless session bean - if I randomly choose a stateless session bean from the pool and use a method of that bean, can I be guaranteed, without any provisos, of receiving the same result if I then randomly grab another bean from the pool and use the same method with the same method input parameter values?

No it won't because you can get the case where the underlying stateful session bean has disappeared. Therefore, it is not without proviso that your stateless session beans will return the same data, regardless of the instance, for the lifetime of the stateless session bean pool (and the container which runs it).

Maybe we aren't being clear about this. So let us forget about the mechanics. Instead let us get down to specific cases.

You have a stateless session bean that connects to the stateful session bean. Nothing else can access that stateful session bean to keep it active except the stateless session bean. You have a hit or miss chance of accessing a session bean connected to a particular stateful session bean to stop that stateful session bean from being passivated, much less destroyed.

Therefore, for your design you will need to take care of the exception in your stateless session bean and create a new stateful session bean if the old one is destroyed.

Or make the stateful session live for ever. Except this is a problem if the stateless session bean is destroyed such as when the container is shut down or the number of stateless session beans shrink to the pool minimum. This is because you will have orphaned stateful session beans.

Those are the options open to you under your current design guidelines.

Why do you need a stateful bean if they are
all equivalent?
The idea of stateful beans is to store client state.

NOTE: Stateless beans means they are stateless
with respect to the client not internally.
A stateless bean can store state that is only
used for the internal processing of requests.

To answer your specific question:

These paremeters control the removal
<remover-period>1800</remover-period>
<max-bean-life>1800</max-bean-life>

These control the passivation (writing to disk
when unused to free memory)
<overager-period>300</overager-period>
<max-bean-age>600</max-bean-age>

As you say, a runtime or remote exception
will also remove the stateful bean.

Regards,
Adrian