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