Java Beans - Question about Stateless Session Beans and creation

Author

Question about Stateless Session Beans and creation

the Rat

2005-12-02, 9:11 pm

All,

I've got a pretty straight forward question that I haven't been able to
find the answer to with regards to stateless session beans and
creation. My question is, once a clientA invokes a method on a bean
instance X, can another clientB invoke a method on bean instance X
before clientA finishes?

I've been assuming that this is possible - that's it's really up to the
application server (jboss, jrun, weblogic, etc) to determine this for
themselves. Because of this assumption, I've been very wary about
storing things like database connections inside my stateless session
bean's instance variables. I'd hate to have clientA come along, grab
access to bean instance X, create a connection and store it in bean
instance X and then, before clientA is finished with the bean, clientB
comes along, notices that connection that clientA stored inside the
bean instance, and uses it. You could see how this could cause I
problem.

Am I being too cautious? Is it really possible for 2 or more clients
to be accessing the same bean instance at the same time?

Any light you can shed would be appreciated.

Thanks,

-john

Doug Pardee

2005-12-02, 9:11 pm

You are being too cautious. Only one client/thread can be running a
method in a given SLSB instance at one time. Which means that only one
method in a given SLSB instance can be active at one time. Of course,
once you return from the method, the SLSB instance is returned to the
container, where it may be tossed into a pool for reuse or may be
destroyed.

>From the EJB 2.0 Specification, section 7.5.6: "A container serializes
calls to each session bean instance. Most containers will support many
instances of a session bean executing concurrently; however, each
instance sees only a serialized sequence of method calls. Therefore, a
session bean does not have to be coded as reentrant."

>From section 7.11.8: "The container must ensure that only one thread
can be executing an instance at any time. ... a session object is
intended to support only a single client. Therefore, it would be an
application error if two clients attempted to invoke the same session
object. One implication of this rule is that an application cannot make
loopback calls to a session bean instance."

The container can generally obtain additional SLSB instances rather
easily, either by simply creating them or - if creation involves some
lengthy operations and you've therefore chosen to set up a bean pool -
from the pool. There's no need for the container to reuse an instance
that's currently active, and it's not allowed.

As a more general statement, a given EJB instance can NEVER be
servicing two different clients/threads at the same time. All EJBs of
every type are absolutely single-threaded. The container will never
allow a method call on any EJB instance while another method call is
active in that instance, EXCEPT for entity beans which have been marked
"reentrant" by the programmer and where the new method call is in the
same transactional context as the active method call(s) - that case is
assumed to be a loopback call (which you'll recall from above is not
allowed at all for session beans). Since a transactional context cannot
be shared between clients/threads, the rule still holds that all EJBs
are absolutely single-threaded.

the Rat

2005-12-02, 9:11 pm

Doug, thanks very much for this - it's just what I was looking for.

-john

Sponsored Links