Good point. At least from where I stand you won't get unacceptable
latency, you will get a timeout if the client is not services within an
acceptable response time (say 10 seconds). If you try to abuse the
server by overloading too many clients (Servlets) on a too small pool
you start getting these timeout exceptions. The TCP/IP stack (and so RMI
and HTTP) work pretty much the same way.
But as long as your pool size is sufficient in size, then you can easily
pipe say 200 requests over 20 beans (remote interfaces) into 50
instances. (Assuming 50 instances are sufficient for 200 method
requests).
At any rate you should try to avoid a one bean per session context
scenario, you can have any number of concurrent requests in the same
context. In contrast, one bean per session scenario is less problematic,
the Servlet engine serves as a bandwidth choke in front of the EJB, and
the EJB can properly synchronize (if only it were allowed to).
arkin
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.
>
> -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".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
