Using Stateles Session Beans in EJB3
I hope someone can clarify this for me.
In EJB2, we would lookup a Stateless Session Bean, use the assorted methods on it, and then call remove() on the bean to free up the reference and clean up resources (notably for remote clients).
But since in EJB3 our local interfaces are simple interfaces, and not extended an EJB specific interface, we no longer have access to the remove method.
Also, in the JEE 5 tutorial, the example they have does not call remove either.
So I take it when we're done with a Stateless Session Bean, we don't have to take any action any more? Is that correct?
[621 byte] By [
whartunga] at [2007-10-3 11:18:02]
Great question! First off, even in the EJB 2.x and earlier programming model, you don't
need to call remove() on a stateless session bean.Since there is no relationship between
the client and any particular stateless session bean instance, remove() is basically a
no-op.The container *can* use it as a hint to release some resources but almost all
ejb containers just ignore it.Ours (SUN's) ignores it.
However, your question does apply more to the stateful case, since removal is an
important issue there.There is no client-visible remove() method on an EJB 3.0
local or remote business interface.In EJB3, there's an @Remove annotation that
can be applied to one or more business methods.If one of these business
methods is invoked, the bean will be removed after the method returns.
In the stateful removal case, yet another option is to expose a 2.x Home or
LocalHome from the EJB 3 bean. A stateful session bean can have
any combination of 1 Home/ 1 LocalHome / N EJB3 Local Business
N EJB 3 Remote Business interfaces.A client interested in the 2.x
view of a bean that is implemented to the EJB3 API has access to the
EJBObject/EJBLocalObject methods.We have a simple example of
this approach here :
https://glassfish.dev.java.net/javaee5/ejb/examples/Adapted.html
--ken
--ken
ksaksa at 2007-7-15 13:42:31 >
Thanks Ken. I was always under the impression that we needed to remove(), especially for remote calls, to free up some server resources.
But now with this I have a follow up question.
In the tutorial, we have this:
InitialContext ic = new InitialContext();
converter = (Converter)
ic.lookup(Converter.class.getName());
Before we would get the BeanHome interface, and then call create() on it to get an actual Sesson Bean interface, and we'd then call our business methods from that.
Also, we were allowed to cache the BeanHome interface so we didn't have to continuarlly do JNDI lookups. So a utility method could cache those Home instances lazily as it looked up the various Session Beans in the application.
For methods on the container side, we can use @EJB for injection of instances in to our code. But on the web app side, we can't use injection.
But now, since we skip the BeanHome lookup step, can we cache the Session Bean instances? In this case, can I stuff 'converter' in to a cache that's accessible across threads on, say, a web app? Is it thread safe if I share it? Do I need to be aware of the lifecycle for the bean to clean up the cache (like in a DB Pool scenario being aware that a connection dropped). Mind, I'm mostly concerned with local calls with the web app bundled in with the EJBs, not remote calls.
Thanx again Ken.
Hi, definitely a few things to clarify !
First, the caching/sharing properties have more to do with the difference
between stateless and stateful session beans than Remote vs. Local
or Home vs. ejb reference.The bottom line is that any *Stateless* session
bean Home/LocalHome or EJBObject/EJBLocalObject/Remote Business reference/
Local Business reference is sharable and thread-safe. That holds true no matter
whether the client code is running within an ejb component, a web component, or
an Application Client component.So, for example, in the web tier it's fine to store such
objects in the HttpSession or web application context.
In the case of Stateful session beans, the Homes are sharable/threadsafe,
but the ejb references themselves are not, since each bean is intended
to be used by a single client.If more than one concurrent request is made to the
same stateful session bean, it is legal for the container to throw an exception.
Regarding injection, it IS supported in the web tier, but only in certain kinds of
managed classes such as servlet classes, JSF managed beans, and servlet
web service endpoints.
So, the platform will *allow* you to inject a stateful session bean reference into
a servlet, but it still means you need to be careful in using it.In practice, it's
not the best idea to inject stateful session bean refs(or any non-concurrent
resource such as EntityManager) into a servlet instance due to the concurrency issues.
Finally, you don't have to worry about the lifecycle of the stateless session beans you're
using. For stateful beans it depends on the semantics of your application but
in many cases you will want to explicitly control removal.Even if you don't
do that programmatically, most ejb containers have configuration parameters
to controls the automatic passivation and/or removal of unused stateful session
beans.
--ken
Clarified first sentence in last paragraph
Message was edited by:
ksaks
ksaksa at 2007-7-15 13:42:31 >
Hi Ken,
I would like to confirm your statement
"The bottom line is that any *Stateless* session
bean Home/LocalHome or EJBObject/EJBLocalObject/Remote Business reference/
Local Business reference is sharable and thread-safe."
So it means we can cache the StatelessBean to be reused by other client, in order to prevent another JNDI lookup ?
Thanks...
Regards,
Ferry
> So it means we can cache the StatelessBean to be> reused by other client, in order to prevent another> JNDI lookup ?Yes, absolutely. --ken
ksaksa at 2007-7-15 13:42:31 >
