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