0

Head first EJB states that in the case of stateless session beans:

Clients don't share EJBObject, but the same bean can serve multiple EJBObjects

I don't see any reason why a single EJBObject cannot serve multiple clients.
Furthermore, if what the book states is correct, what is the advantage we get from pooling beans if we have to create one EJBObject per client ?

GionJh
  • 2,742
  • 2
  • 29
  • 68

1 Answers1

1

First of all, one has to understand what an EJBObject is:

The EJBObject interface is extended by all enterprise beans' remote interfaces. An enterprise bean's remote interface provides the remote client view of an EJB object. An enterprise bean's remote interface defines the business methods callable by a remote client.

With that being cleared, consider the following local EJB example:

public class SomeClass {

    @EJB
    private SomeBean someBean;
    ...
}

Basically, our EJBObject is nothing more than an attribute of our class SomeClass which references the EJB SomeBean.

What's happening is that, on the container's point of view, he's not really creating and injecting a dedicated instance of the EJB SomeBean. Instead, he's instantiating the EJB SomeBean, storing it in his EJB pool, creating a proxy for this instance and injecting the proxy in on our class SomeClass.

Therefore, for each client, you have a single EJBObject or proxy but, under the hood, as the Head First states, the same bean can serve multiple EJBObjects.

...what is the advantage we get from pooling beans if we have to create one EJBObject per client?

Well, for instance, thread-safety: if you have several instances of SomeClass, calling concurrently the same method of someBean, it is guaranteed that those calls will never be delegated to the same instance since Stateless session instances are dedicated to an EJB object only for the duration of a single method call.

Other advantages of EJB pooling can be found on this answer by Will Hartung. :)

António Ribeiro
  • 4,129
  • 5
  • 32
  • 49
  • Annotations don't work in remote clients so, your code snippet is incorrect. In remote clients, JNDI should be used to look up remote objects. – lupchiazoem Aug 03 '18 at 08:36
  • Your statement - "it is guaranteed that those calls will never be delegated to the same instance" is incorrect. The container may choose same instance. For instance, lets say there's a pool of 50 SLSBs. Client A makes a call and is assigned an instance. While this call is in process, lets say there are 49 other calls. So, the pool is empty now. Client A is done with its process and its associated SB is sent to pool. While other 49 SLSBs are still under process, now if the Client A makes another call, the container will assign same instance which was allocated first as its only the free one. – lupchiazoem Aug 03 '18 at 08:47
  • @mnmopazem first of all my code snippet **is correct** for local clients. Second of all, I'm not referring to any remote clients which you may argue is missing, that I agree. Finally, you ought to read carefully my answer before making any remark: I stated that **a concurrent call** will never be delegated to the same instance. The example you provide isn't at all related to what I've stated. – António Ribeiro Aug 03 '18 at 09:00
  • My statement is w.r.t a context which is specified in your answer. The `EJBObject` link that you specified points to JEE 6 API and `EJBObject` extends a remote interface. – lupchiazoem Aug 03 '18 at 09:07
  • Regarding concurrent call, I agree that example is unrelated to context. My apologies. – lupchiazoem Aug 03 '18 at 09:27
  • Edited my answer's example in order to comply with the EJB type. Thank you for the input. – António Ribeiro Aug 03 '18 at 09:39