anne,
truely great explaination . you cleared my lots of funda .
well can you or anybody in this list throw some light on
context object.
like what is it's life cycle and functionality as a whole.
TIA,
pravin
Anne Thomas <[EMAIL PROTECTED]> on 10/26/99 11:20:26 PM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: Pravin Tiwari/LTITL)
Subject: Re: Basic Session Bean lifecycle question
Ken,
1. JNDI has a reference to the home object -- if the object isn't currently
alive, the EJB server will activate it when it is called. (generally there
is only one home object per object type in a container)
2. The client uses the home object reference to create the session bean.
For
stateful session beans, the container normally creates a new instance of
the
bean and associates it with an EJBObject and a context object, and the home
returns a reference to the EJBObject. The EJBObject and the stateful
session
beans are unique to the client. For stateless session beans, the create
request may not need to actually touch an instance of the bean. The
container allocates an EJBObject and associates it with a context object,
and the home returns a reference to the EJBObject. The EJBObject is unique
to the client, but the stateless session beans can be shared by all
clients.
Once the client has the reference to the EJBObject, it can call methods.
For
stateful session beans, the EJBObject processes each method request,
applies
the necessary services (transaction, security, state management, etc.) and
delegates the method request to the associated stateful session bean. If it
is a stateless session bean, the EJBObject calls the container to allocate
a
session bean from the session bean pool. The EJBObject applies the
necessary
services and delegates the method request to the bean, and when the request
is complete, it frees the bean which gets returned to the pool.
3. If the container determines that it must regain resources, it might need
to deactivate an active stateful session bean. Before deactivating the
session been, it calls the passivate method (which should release any
resources that it's holding, such as a network or database connection), and
then it serializes the object to some type of persistent store
(vendor-dependent). I don't think it frees the EJBObject. (It would be an
implementation issue -- the container would need to save the EJBObject
state
so that it could retrieve references for the context object and the bean).
The next time that the client calls a method, the EJBObject calls the
container to reactivate the bean. The container retrieves the serialized
object and calls the activate method (which allows the object to obtain the
resources that it freed on deactivate), and then executes the method. The
bean developer does not need to save and store the session state. The
container does that automatically. The activate and deactivate methods can
be empty if the bean isn't holding resources.
-----Original Message-----
From: Kenneth D. Litwak [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 25, 1999 2:20 PM
Subject: Basic Session Bean lifecycle question
I have a basic question about session bean lifecycle. Here's how I
understand
what happens.
1. A client connects to the EJB server, using a reference to the home
object
from JNDI. Or does JNDI have a reerene to the factory that produces home
objects and uses the appropriate interface to call for a home object? Or?
2. The caller uses the reference from the home object to call methods on
the
bean via the EJBObject. This EJBObject and the corresponding session bean
instance are unique and speciic to a gien client.
3. Even though the client has not called remove, it is perfectly
possible
for
the container to discard a stateful session bean instance (and its
corresponding
EJBObject) after a client call. To deal with this the bean developer needs
to
put code in activate andpassivate methods to save and restore the session
bean
state. The new instance is found thorugh the handle the client already had
to
the EJBObject.
This is what I think happens. Please tell me if this is right or what is
different. Thanks.
Ken
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
