On 9 Jan 01, at 9:14, Rickard Öberg wrote:
> Hi!
>
> Ole Husgaard wrote:
> > When doing simultaneous calls to the same stateful
> > session bean I sometimes get a RemoteException:
> > "Application Error: tried to enter Stateful bean with
> > different transaction context"
> >
> > This exception is correct; that is exactly what I am
> > trying to do. In current CVS this is thrown from
> > StatefulSessionInstanceInterceptor line 169.
> > However, I would prefer that this exception not be
> > thrown, and the InstanceInterceptor instead wait
> > until the current invocation is finished.
>
> Well, tell that to the EJB spec writers. We follow the specs, which say
> that an exception must be thrown on reentrant calls to stateful
> sessions.
>
[snip...]
>
>
> See above, the stateful session behaviour may not be changed. At least
> not in JBoss core. If you want to do local changes, that's fine, but you
> may not add them to JBoss CVS. Sorry Ole :-(
>
Hi Rickard & Ole,
In the proposed final draft of the EJB 2.0 specification, page 66,
footnote (4), regarding multiple concurrent requests to a stateful
sesion bean, the following is stated:
"In certain special circumstances (e.g. to handle clustered web
container architectures), the container may instead queue or
serialize such concurrent requests. Clients, however, cannot rely
on this behavior."
Rickard is correct that, from a portable client's point of view, you
must assume that a RemoteException will be thrown. However, I
do not think that Ole's proposed change would be a violation of the
specification. If we do provide queueing behavior for stateful session
beans, we might want to make it optional. That way, a developer
who wanted strict portability would not be misled.
I'm not a big fan of stateful session beans in general. However,
IMHO Ole's proposed change increases their potential usefulness
in a web architecture, especially with a stateless load-balancing
scheme.
-Dan
