At 15.47 11/04/2001 +0200, Philippe Durieux wrote:
>Filippo Bosi wrote:
> >
> > The Stateful Session Bean pooling mechanism implemented in
> JBeanSession.java seems to violate the
> > EJB specs. In fact in the EJB specs (version 2.0), Chapter
> > 6, Paragraph 6 (Stateful Session Bean State Diagram) says
> >
> > "A session bean instance?s life starts when a client invokes a
> create<METHOD>(...)
> > method on the session bean?s home interface. This causes the container
> to invoke newIn-
> > stance() on the session bean class to create a new session bean
> instance. Next, the container
> > calls setSessionContext() and ejbCreate<METHOD>(...) on the instance and
> > returns the remote reference of the session object to the client. The
> instance is now in the
> > method ready state."
> >
> > The problem is that the object pooling mechanism does not guarantee
> > proper re-initialization of the bean instance with default values
> > (that is nulls for object references, false for boolean variables, and so
> > on...) when a Stateful Session Bean gets reused by another client that
> > invokes create().
> > On the contrary, invoking newInstance() on the container side for every
> > client call to create(), as stated on the EJB specs, guarantees
> > the Bean Provider with proper initialization of the bean instance
> variables.
> >
> > On the other side, the object pooling mechanism implemented in
> > JSessionBean.java works perfectly with STATELESS Session Beans. In the
> > EJB specs (paragraph 6.8.1), in fact, you can read
> >
> > "A stateless session bean instance?s life starts when the container
> invokes newInstance()
> > on the session bean class to create a new instance. Next, the container
> calls setSessionContext()
> > followed by ejbCreate() on the instance. The container can perform the
> > instance creation at any time-there is no relationship to a client?s
> invocation of the create()
> > method."
> >
> > Thus, the only way to follow the EJB specs and have a Stateful Session
> > Bean pool would be to ensure, when an object is reclaimed from the free
> > pool, the respect of the Class.newInstance() semantics, without the object
> > creation phase. The problem is that it seems it's impossible to obtain
> > this behaviour (that is decoupling the object creation phase from the
> object
> > initialization phase) using any of the reflection API.
> >
> > Filippo
>OK. I understand the problem. The pool had been done to improve performance of
>create session stateful beans. If you think that this is not correct, and if
>you think that creation time is not so important, the fix is quite easy:
>We can simply remove the pool of session stateful bean instances.
>What do you think of all this ???
Thank you for your prompt reply!
I think this is the only viable solution, at the moment. The point is that you
can't re-initialize a pooled object without knowing it's initialization
semantic.
Maybe this should be a RFC we could issue to Sun regarding Reflection API.
Everything is ok, on the other hand, with Stateless Session Beans, where
you don't
rely on any session data being properly re-initialized between subsequent
reuses
of the same Bean Object.
WRT the performance problem, I think it's not a big performance hit if you
don't
reuse Stateful Session Beans. They're 1:1 with a client and they usually
have the
same lifespan as the client. It should have been a major concern if you
hadn't implemented
pooling on Stateless Session Beans.
Regards,
Filippo
>--
>Philippe Durieux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Bull - 1 rue de Provence - 38432 Echirolles Cedex France
>[EMAIL PROTECTED]
>-> Download our EJBServer at http://www.evidian.com/ejb <-
----
This list is cross-posted to two mail lists. To unsubscribe,
follow the instructions below for the list you subscribed to.
For objectweb.org: send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe ejb-container-group".
For enhydra.org: send email to [EMAIL PROTECTED] and include
in the body of the message "unsubscribe ejb-container-group".
