Yes, this is by design. In GlassFish, when a StatelessSessionBean
instance is required, the
container (StatelessSessionContainer) attempts to obtains one from
the bean pool. If
the pool is empty then a new instance is created.
The reason is to NOT to block an incoming request due to lack of
instances. When the
request completes, the bean instance will be returned to the pool.
If the pool is
already at max-pool-size, the bean instance is destroyed.
On 9/25/14, 10:57 AM, Olivier Liechti wrote:
> Hello,
>
> I am trying to understand in details how the EJB pool is managed by Glassfish, in terms of instance creation. I have been a bit surprised by what I have observed and would like to confirm my understanding.
>
> 1) Let me start with what I initially thought. The scenario is that an HTTP request comes in, is handled by a servlet which makes a call to a SLSB. The @EJB annotation has been used in the servlet. In my test setup, I do a Thread.sleep(10000) in the SLSB business method. That allows me to exhaust the bean pool quickly. I opened a few tabs in my browser and called the servlet several times in parallel. I expected to observe a variation in the number of instances in the pool, with a new instance created for every request.
>
> 2) Actually, I did not observe that. My understanding is now that a new instance is created for each HTTP session. Indeed, if I send requests from different browsers, then I see the number of EJB instances go up.
>
> I had a quick look at the source code, but was unable to confirm my understanding. (https://svn.java.net/svn/glassfish~svn/branches/4.0/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/containers/StatelessSessionContainer.java)
>
> So, couple of questions:
>
> - is my understanding in point 2 correct?
> - if so, is that a feature or a bug? If it's a feature, what are the reasons?
>
> Many thanks for your feedback,
>
> Olivier
>