How @EJB annotation is processed in EJB container 3.x from the moment when we deploy ejb components?

0
votes

Questions about ejb session bean behavior when used as injected bean instances. I'm not 100% sure how this works. I guess it from practice and from reading documents on the subject. I want to know how @EJB annotation is processed by container in detail.

Session bean have interfaces, impl class, deployment descriptor. We package them in ejb jar.

  1. What is putted in global JNDI by container? Static references to business interfaces ?
  2. How and when global JNDI is read from ?
  3. When component JNDI ENC is populated with ejb reference ?
  4. Is this reference in JNDI ENC (java:comp/env/beanB) is reference to session bean component interface, session bean instance proxy or session bean instance ? Is there difference for SLSB and SFSB ?
  5. With @EJB annotation on field does every new ejb session bean instance get new instance of injected ejb in the annotated field or all ejb instances share the same injected ejb session bean instance ?
  6. Does ejb injection by lookup (on session context) provide always new injected ejb instance, example: calling ctx.lookup(ejbReference) in loop ?
1
ejbejb-3.0ejb-3.1

1 Answers

1
votes
  1. In EJB 3.0, the JNDI names are vendor-specific (if available at all; in theory, a container could support EJB references only), but vendors typically return an EJB reference/proxy. In EJB 3.1, the specification requires the EJB container to make specific java:global, java:app, and java:module names available, and the object returned from these lookups must be an EJB reference/proxy.
  2. The global JNDI is accessed when you perform a JNDI lookup. The container might access the global JNDI names in other cases (e.g., when resolving @EJB(lookup="java:app/...")).
  3. It's undefined when the container populates java:, but the contents must be available before lifecycle callback or business methods are invoked on the component instance.
  4. @EJB/<ejb-ref>/<ejb-local-ref> ensure lookups always return an EJB reference/proxy and never an actual bean instance. The proxy ensures that all container services are performed (security, transaction, remoting, etc.) before invoking an actual bean instance. For SLSB, an arbitrary bean instance will be invoked, and the same or different actual instance might be invoked depending on the thread, concurrency, timing, vendor-specific configuration, etc. For SFSB, a bean instance with a specific identity will be invoked; you are likely to get the same bean instance, but you might not if the EJB container has passivated the actual bean instance, but reactivation should result in an instance with equivalent state. For singleton session bean in EJB 3.1, you are guaranteed the singleton bean instance will be invoked.
  5. It's undefined whether you get the same proxy instance. For SLSB and singleton beans, injection or lookup could return a single proxy that delegates to the actual bean instance as mentioned above. For SFSB, the proxy is basically required to be a separate instance per injection or lookup since the proxy must store some state with the identity so it can invoke the specific actual bean instance.
  6. It's undefined what the container does, but injection is typically implemented by containers using Context.lookup followed by Field.set (or Method.invoke for setter method injection). Regardless, the instance handling is as described above.