EJB 3.1 injection vs JNDI lookup

[Claude Moore]

Hello everyone,

I really need your help to understand a thing I uncounsciously always considerated as obvious...but that's not really clear in my mind.

So, I knew for sure that a good characteristic of EJB is the fact that the container is able to "scale" their instance number with respect
to actual request load it has to fulfill.


So, in a servlet, I used to adopt this schema before EJB 3.1 adoption:

public void executeRequest(HttpServletRequest req, HttpServletResponse resp) throws Exception {
        MyEjb ejb = lookup(....) ; // pseudo-code to lookup required EJB
        ..... //
        ejb.methodA();
       .....

}

At each request, I used to lookup required SLSB and do some work. The more requests were send, the more the number of instances the container created
(I was able to verify this fact using my appserver admin console, which reported the number of ejbs created / destroyed...of course i was able to simulate
a variable number of request of service).

Now, with injection mechanism, I usually write:

@EJB
MyEJB currentEJB;

.....

public void executeRequest(HttpServletRequest req, HttpServletResponse resp) throws Exception {
      /// No lookup at all
      .....
      currentEJB.doStuff();
      .....
}

So, in this last scenario, if I'm not wrong and I understood both servlets' and ejbs' lifecycle, there will be
a single servlet instance which doGet, doPost methods are concurrentially executed by threads asociated
to the web requests, and in each request the very same instance of MyEjb is accessed and used.

Is that wrong ? If not, it seems that with injection we eventually have a single instance of an ejb for each artifact
that requires a reference to it; if so, the property to scale with respect to the load is still valid ?

Please help me to understand.

[Jaikiran Pai]

Irrespective of whether you do a manual lookup or inject the bean, underneath, a proxy is returned/injected. This proxy isn't really the bean instance. Invocation on this proxy ultimately leads to a point, where the bean instance "selection" happens, which depends on various factors including the type of the bean and like you say the "load" on the bean.

So injecting a bean doesn't mean you'll inject a single instance of the bean always.

[Claude Moore]

Thank you for your reply...
So, if I understood what you are telling me, I got a reference (which is one in the Servlet injection case), but under the hood the actual instance of the EJB the reference points to may change at
every request ?
This would explain a lot of things...

[Jaikiran Pai]

Claude Moore wrote:
So, if I understood what you are telling me, I got a reference (which is one in the Servlet injection case), but under the hood the actual instance of the EJB the reference points to may change at
every request ?

Yes that's correct.

[Claude Moore]

Thanks Jaikiran.... It's enough for me. I think that under the hood, the EJB container creates a pools of EJBs and manages its size and assignment to "references" or "proxies".
Thanks again for your help.

[Michael Remijan]

Servlets aren't singletons either. Not sure if that configuration was removed in EE 7 but you can have multiple instances of servlets pooled just like EJBs to handle incoming requests. This pooling is all handled by the app server.

[Claude Moore]

Yes, that's true... thanks for your reply Michael.