I don't have Monson-Haefel's book, so the context of his comment is not
evident to me.  Howver, it is very important to understand that although
stateless session EJBs do not maintain _conversational_ state, they may
indeed maintain other kinds of state -- for instance JDBC Connection and
Statement objects (among many other possibilities).  From the client's
viewpoint every method invoked on a stateless session bean might as well
be invoked on any instance of that bean provided by the container, and
from the bean's perspective it is always acceptable for any object to
invoke any of its exposed business methods (questions of concurrency
aside for a moment).

But suppose a stateless session bean holds a Connection and an
associated PreparedStatement, with which it fulfills invocations of one
of its business methods.  That's perfectly acceptable because these
objects do not change based on business method invocations.  Now suppose
that while it is in the middle of executing that method for one client,
processing the ResultSet returned from the PreparedStatement, another
client invokes that method again.  When the PreparedStatement is
executed again, the previous ResultSet associated with it is closed; but
the other thread is not yet done with it!

What a stateless bean cannot do is cache the ResultSet and allow future
method invocations to process it further.  In that case the ResultSet
would consitute an element of conversational state between the client
and the bean, which is exactly what is not permitted of stateless beans.

In general EJBs have exactly the same kinds of concurrency issues that
any other objects have.  Their contracts with client and container
constrain their architecture and operation, but not so much as to
eliminate all possible concurrency problems, even for stateless session
beans.

John Bollinger
jobollin@indiana.edu