why cant Stateless Session EJBs allow concurrency - Java

Raj wrote:

> From this EJB book I am reading (Richard Monson-Haefel) it says that
> all EJBs do not support concurrency by default. Why should this be so
> in the case of Stateless Session ejb's because in any case it does not
> store any state information.
>
> I know this may sound like a silly question... Why can we just use
> static methods instead of stateless session ejb's?

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

Thanks for your reply. In regard to your example about multiple
threads making database calls via the JDBC api, concurrency issues
will arise only if any of the objects (connection, statement,
resultset) are members of the class. If they are locally defined,
which I believe it should in the case of stateless session EJB(SSB),
then it should not matter whether it is being called by a single
thread or multiple threads. I am trying to understand what is special
about the SSB that does not allow concurrent access. Obviously this is
the reason that SSB's are pooled in order to handle multiple requests.
My understanding of this makes be want to say that only one instance
of an SSB is sufficient to handle any number of requests. What do you
say?

Thanks!

Raj

"John C. Bollinger" <jobollin@indiana.edu> wrote in message news:<bugrhd$8me$1@hood.uits.indiana.edu>...
> Raj wrote:
>
> > From this EJB book I am reading (Richard Monson-Haefel) it says that
> > all EJBs do not support concurrency by default. Why should this be so
> > in the case of Stateless Session ejb's because in any case it does not
> > store any state information.
> >
> > I know this may sound like a silly question... Why can we just use
> > static methods instead of stateless session ejb's?
>
> 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

Raj wrote:

> Thanks for your reply. In regard to your example about multiple
> threads making database calls via the JDBC api, concurrency issues
> will arise only if any of the objects (connection, statement,
> resultset) are members of the class. If they are locally defined,
> which I believe it should in the case of stateless session EJB(SSB),
> then it should not matter whether it is being called by a single
> thread or multiple threads.

You have completely missed the point, which is that SSBs are allowed to
have member variables without restriction, and to use them in the
execution of their methods. Declaring a session bean "stateless" in its
deployment descriptor is a promise about its behavior, not a statement
about its structure. The promised behavior is that the execution of a
business method by any client will never change the result of a later
execution of the same or any other business method on behalf of the same
or any other client. It is about how the _container_ can use instances
to fulfill requests.

> I am trying to understand what is special
> about the SSB that does not allow concurrent access. Obviously this is
> the reason that SSB's are pooled in order to handle multiple requests.

Again, you have missed the point. _Nothing_ is special about SSBs or
any other kind of EJB with regard to concurrent access, which is exactly
why they are not suitable for concurrent access. I gave you the
skeleton of a viable example of an SSB that in fact has a real
concurrency problem.

> My understanding of this makes be want to say that only one instance
> of an SSB is sufficient to handle any number of requests. What do you
> say?

I say reread what I wrote before, and what I have written above. If you
want a truly authoritative answer then the ultimate resource is the EJB
spec, available free from Sun. You seem to be making assumptions about
the meaning of "stateless" that are not appropriate in this context, so
if you read the spec then take care to not read in requirements that are
not actually there. If it is not in the spec then it is not a requirement.


John Bollinger
jobollin@indiana.edu

> Thanks!
>
> Raj
>
> "John C. Bollinger" <jobollin@indiana.edu> wrote in message news:<bugrhd$8me$1@hood.uits.indiana.edu>...
>
>>Raj wrote:
>>
>>
>>>From this EJB book I am reading (Richard Monson-Haefel) it says that
>>>all EJBs do not support concurrency by default. Why should this be so
>>>in the case of Stateless Session ejb's because in any case it does not
>>>store any state information.
>>>
>>>I know this may sound like a silly question... Why can we just use
>>>static methods instead of stateless session ejb's?
>>
>>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