Whew!!! That is a relief. Thanks for that clarification.
For a moment from the previous poster's notes, I was under the impression
that IAS allowed re-entrancy to beans, which gulp!! poses a multitude of
problems.
-- Aravind
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan K. Weedon
> Sent: Friday, 12 May 2000 09:48
> To: [EMAIL PROTECTED]
> Subject: Re: Queuing requests to a Session Bean
>
>
> <vendor>
>
> Just a quick note here, as I believe people are thinking that we have
> somehow violated the EJB specification w.r.t. re-entrant calls to
> stateful session beans: we have not.
>
> We provide exactly the capabilities for stateful session beans as
> defined in the EJB 1.1 specification: no more and no less. If anyone
> knows otherwise, it is a bug.
>
> What we do provide, along with a number of other vendors, is the
> ability to run a mix of CORBA servers and EJB objects. Thus, if you
> want a reentrant stateful object (i.e., a singleton), we do provide
> this, by way of a CORBA server.
>
> Furthermore, if you prefer using RMI-style signatures, you can
> implement this CORBA singleton using RMI-style signatures, allowing
> convenient Object-by-Value support. Furthermore, if you want, you
> can bind this object into the naming service using JNDI instead
> of CosNaming (or actually, using JNDI on top of CosNaming).
>
> This duality between CORBA objects and RMI/EJB objects all comes for
> free by virtue of the fact that we provide a complete RMI-over-IIOP
> implementation, where our RMI objects are in fact simultaneously
> CORBA objects, and are thus fully IIOP enabled, and full "citizens
> of the CORBA world". But again, this is just an added value in the
> CORBA space; it by no means a pollution of the EJB model.
>
> Just wanted to clarify.
>
> </vendor>
>
> -jkw
>
> Chris Raber wrote:
> >
> > Curt,
> >
> > I aggree that more flexibility is needed in this area. However
> I am Slightly
> > concerned about re-entrant calls to stateful beans. The bean
> programmer then
> > has to worry about mutex and stuff, which is what the spec is trying to
> > avoid.
> >
> > In the case of the stateless case, the container can route the
> invocations
> > to pooled bean instances. No harm no foul. I've never quite
> grocked why the
> > limit in the stateless case. Conservatism and perhaps consistency in the
> > minds of the spec designers???
> >
> > Regards,
> >
> > -Chris.
> >
> > > -----Original Message-----
> > > From: Smith, Curt H. [SMTP:[EMAIL PROTECTED]]
> > > Sent: Thursday, May 11, 2000 2:59 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Queuing requests to a Session Bean
> > >
> > > > A third alternative is to Not use Stateful beans, but use
> > > > http session state
> > > > for session state management, and use stateless beans for
> > > > your services
> > > >
> > >
> > > The limitation of serialized calls to EJB has been one of my
> > > frustrations with EJB. This thread is the result.
> > >
> > > There needs to be another type of EJB that's closer to the
> > > corba service capabilities: memory efficient server side,
> > > concurrent dispatching of method calls on a shared _Impl
> > > etc.
> > >
> > > Or why not use an Appserver vendor that also supports corba
> > > servants: IAS, Gemstone, ??. WLS is out as are most of the
> > > late commer appservers that didn't start out in life as corba
> > > orbs.
> > >
> > > Another thought, is to use a appserver that allows reentrant
> > > calls into a bean controlled in the DD. IAS supports this.
> > > This posters problem would be non-existant. He'd just have to
> > > design the business logic to tolerat reentrant calls into
> > > the stateful session bean, which is what us server side guys
> > > have been doing for ages,,, until EJB came along and moved
> > > the complexity of client-server over the client side where
> > > it never was, for good reason. :) LOL, EJB, what a mess,
> > > now the client developers need to be the rocket scientists.
> > >
> > > LOL
> > >
> > > curt
> > >
> > >
> > > Curt Smith
> > > Z-Tel
> > > email: [EMAIL PROTECTED]
> > > work: 404-237-1166 x182
> > > FAX: 404-237-1167
> > >
> > >
> ==========================================================================
> > > =
> > > 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".
>
> ==================================================================
> =========
> 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".
