> > Another thought, is to use a appserver that allows reentrant
> > calls into a bean controlled in the DD. IAS supports this.
>
> Does this not violate the specification ?
Yes. My point. The spec needs more flexibity or another
service type defined. There's a _large_ number of commong problems
left with no good solution with EJB 1.1.
A few have chirped-up including myself and offered that good'ol
corba servers solve the concurrent accessed stateful service
or the singleton service model very nicely.
Why force this problem into an EJB when it doesn't fit??
>
> > 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.
> >
>
> One of the main reasons they did not allow re-entrant calls
> into an EJB is
> to reduce the complexity of the business code. As others have
> pointed out,
> there are various ways in which your client side can also not
> be complex in
??? I really haven't seen _good_ solutions that where performant
mentioned so far?
I've seen _really_ slow solutions that did synchronzed (some_obj) {}.
I might as well program in C without threads. LOL :)
I'm just rattling the spec's pages abit, hoping the future EJB
container and spec authors are listening... :)
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".
