Date: Wed, 11 Apr 2001 14:16:34
+0200
To: [EMAIL PROTECTED]
From: Filippo Bosi <[EMAIL PROTECTED]>
Subject: JONAS 2.2.6 stateful session bean pooling violates EJB
specs
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
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
