It depends upon the kind of session bean you have.
If you have a STATELESS session bean on the server, then for every request
coming from the client (and they can come from multiple threads on the
client) and from the same client-proxy (or stub), the server uses a distinct
instance of the bean-impl class. And each of these requests are handled by a
separate worker-thread on the server. In short, for stateless-session beans,
it works as if you had multiple proxies on the client.
For STATEFUL session beans, things get a little trickier. For multiple
requests that are sent to a client-proxy from multiple threads on the
client, the server uses a different worker thread per request. Since
requests on a client-proxy of a stateful-session bean are _always_ sent to
the corresponding server side bean-impl instance, concurrent requests from
the client on a client-proxy causes an attempt at concurrent access on the
bean-impl instance. The server-proxy (or EJBObject) on the server side
catches this and throws an exception when a request comes in targeted at a
bean-impl instance that is already in the process of executing a method. If
the client somehow serialized the access on the client-proxies, the server
will be happy to oblige.
I hope this helps.
Faiz Arni
InferData Corporation
An EJB and J2EE Training and Consulting Company
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Bhattacharyya, Ana
Sent: Tuesday, June 06, 2000 12:35 PM
To: [EMAIL PROTECTED]
Subject: Re: session beans|EJBObject and thread
Hi subbu,
okay sorry again!--- client side objref then serverside skeleton and then
the bean impl instance. now I do the home.create() only once and the
instance/objref that I get is given to multiple threads for invoking methods
on the bean. question is whether one instance of the objref always points to
the same container generated skeleton instance or not?
if it points to the same skeleton instance always then it comes out that one
skeleton instance will map to n bean impl instances.
TIA
Anamitra
ps: dosent the container generated skeleton also implement EJBObject??
-----Original Message-----
From: Subrahmanyam Allamaraju [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 12:55 PM
To: [EMAIL PROTECTED]
Subject: Re: session beans|EJBObject and thread
Hi Anamitra,
> well sorry for the lack of clarity! in my example the objref is the client
> side stuff(proxy to the serverside EJBObject) and EJBObject is the server
> side stuff which actually contacts the sessionbeanimpl instance.
Could you please clarify this? The EJBObject is a client-side object. The
object that delegates the request to the Impl is a container-generated
skeleton, for which the spec does not specify any contract. Which one are
you talking about?
> So both stateless and stateful will throw exception if I use the same
objref
> in multiple threads? what is the case with entity beans then --- they
should
> not crib. but actually the stateless and entity both should not crib as
they
> are not for any particular client -- but the stateful is for a client!
This object reference (the EJBObject instance) need not be thread-safe
irrespective of the type of the bean.
> cheers
> Anamitra
>
> -----Original Message-----
> From: Subrahmanyam Allamaraju [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 06, 2000 12:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: session beans|EJBObject and thread
>
>
> >
> > > > Q1> Now if I again invoke the another method of the objRef then does
> the
> > > > invocation goes to the same EJBObject instance everytime??
> > > > OR it goes to a diffrent EJBObject instance??
> > > > The spec says that a client cant assume that the same bean instance
> will
> > > > service it every time. But can the same EJBObject instace
> > > > service it everytime if the objref used is the same??
> > >
> > > Need not, because the bean above is stateless.
> >
> > Could you please explain this a little bit?
> >
> > My understanding so far was, that the EJBObject is the entity that
> maintains the
> > actual connection to the client.
>
> Sorry for my lack of clarity. I was confused by the question.
>
> In Anamitra's example, what's the EJBObject? The home.create() returns an
> object that implements the EJBObject (and the remote interface). So, what
> create() returns is the container-generated stub. So, the variable
> "register" refers to this stub, and it's the same as long as the client
> holds it.
>
> And you're right in saying that, for the client, this EJBObject holds the
> connection (loosely speaking).
>
> > So I thought, that during the lifetime of a 'session', a client always
> talks to
> > one specific instance of an EJBObject for every EJB it has a reference
to.
>
> Regards,
>
> Subbu
> 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".
STATEMENT OF CONFIDENTIALITY. The information contained in this electronic
message and any attachments to this message are intended for the exclusive
use of the addressee(s) and may contain confidential or privileged
information. If you are not the intended recipient, please notify
USPowerSolutions Corporation immediately at (617) 547-3800, or at
[EMAIL PROTECTED], and destroy all copies of this message and any
attachments.
===========================================================================
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".
