Chris Raber 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.
If the session bean is not stateless, then the servlet engine will allow the
creation of a pool of servlet instances, each of which is used for only one
client at a time.
So whether or not the bean is stateless or stateful, it is easy for vendors
to provide solutions that avoid the requirement to do a home.create(...)
within the servlet's service method using local variables.
<vendor>
Of course I should mention that the above features are present in Sybase
EAServer 3.5, just in case anyone was so impressed that they want to rush
out and buy it :-)
</vendor>
> -Chris.
>
> > -----Original Message-----
> > From: Bob Alcorn [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 19, 2000 4:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Vendor Challenge
> >
> > Question: wouldn't the problem be solved by generating the client _stubs_
> > with synchronization primitives (as opposed to trying to synchronize the
> > bean methods)? In my estimation, that's the crux of this particular case:
> > there's no explicitly stated control mechanism for the synchronization of
> > the reference's methods. The container should be able to handle the other
> > cases without any problem, since it controls the relationship between
> > client
> > references and actual bean instances.
> >
> > As I understand the EJB development model, the container generates all
> > appropriate stubs and proxies at deployment time. By generating a properly
> > synchronized client stub, the problem goes away, no? Or am I just missing
> > some painfully obvious aspect of the whole problem...
> >
> > --------------------------------------------
> > Bob Alcorn
> > Software Engineer
> > Blackboard, Inc.
> > 1111 19th Street NW, Suite 608
> > Washington, DC 20036
> >
> > --------------------------------------------
> >
> >
> > > -----Original Message-----
> > > From: Frederic Kam-Thong [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, January 19, 2000 10:36 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Vendor Challenge
> > >
> > >
> > > <Weblogic>
> > > Making the [session]bean methods synchronized won't solve any
> > > reentrancy
> > > problem
> > > since an exception would be thrown the moment you even
> > > remotely so try to
> > > "touch"
> > > the session bean from another thread.
> > >
> > > We tried synchronizing on the session bean itself but this
> > > led to a deadlock
> > > in many cases.
> > > Eventually, we ended up storing a lock object (just any plain
> > > object) in the
> > > session and
> > > having every servlet or JSP/JHTML synchronize on a particular
> > > lock for any
> > > given session
> > > if more than one EJB session are kept.
> > >
> > > This obviously requires extra care to be taken by the
> > > developers but it is
> > > only necessary to
> > > do so when a session is accessed by multiple requests(be it
> > > from a frame or
> > > a child window)
> > > on behalf of a single and unique client.
> > > </WEBLOGIC>
> > >
> > > This method could probably applied to a session bean being
> > > shared among
> > > multiple clients(HttpSession)
> > > by storing lock objects in the ServletContext or any other application
> > > context. Haven't tried this though.
> > >
> > >
> > > Frederic Kam-Thong
> > > Invera Inc.
> > > Westmount, Quebec
> > >
> > >
> >
> > ==========================================================================
> > =
> > 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".
--
________________________________________________________________________________
Evan Ireland Sybase EA Server Engineering [EMAIL PROTECTED]
Wellington - New Zealand +64 4 934-5856
===========================================================================
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".
