Reputation: 2894
Head first EJB states that in the case of stateless session beans:
Clients don't share
EJBObject
, but the same bean can serve multipleEJBObjects
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 ?
Upvotes: 0
Views: 120
Reputation: 4202
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. :)
Upvotes: 1