> -----Original Message-----
> From: Evan Ireland [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 7:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Vendor Challenge
>
Evan wrote:
> >
> > The problem with that approach is that if there are many threads try to
> > invoke on the bean simultaneously (because the implementation of
> > synchronization inside the stub seduces the developer into thinking that
> > this is not an issue), then there could be unacceptable latency for the
> > thread at the back of the q.
>
> One way we handle this is to allow the same object reference for a
> stateless
> object to be used simultaneously by multiple client threads. That doesn't
> mean that the same bean instance is used concurrently, in fact each
> concurrent call through the same object reference is serviced by a
> separate
> bean instance.
>
> snip...
Yes of course. But this is not per the specification. The customer's use of
this would be non-standard. Ok as long as the vendor implementation makes
this clear and doesn't seduce the customer into a lock-in trap without
letting them know!
Hey, I promote non-standard stuff we can do all the time! What slimy vendor
doesn't? I also advise customers to have isolation layers that protect them
from lock-in if they are concerned about such things...
Regards,
-Chris.
===========================================================================
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".
