Reposting - This did not make it to the list.

> 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.

I think this is upto the implementation.

> ps: dosent the container generated skeleton also implement EJBObject??

 As far as I understand, the client-side object should implement the
EJBObject, but I don't see any reason why the server-side object should? I'm
interested in finding a reason.

- Subbu

> -----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".

Reply via email to