I am getting lost in this reponse. Let me try to be more specific. If all
servlet requests are piped to the same bean by the servlet, and these
invocations are synchronized to avoid parallel invocations against the bean
(which are disallowed per the spec), then requests against the bean will
queue and the bean becomes a bottle neck. The EJB server can do all the
instance pooling magic it wants, but if the requests queue at the EJB
objects stub, then it does no good.
Given the current spec, my advice is to use a stateful bean per servlet
session context (if stateful semantics are required) or a pool of session
bean references in the servlet engine so that multiple servlets can invoke
against pooled instances in parallel.
Are we on the same page?
-Chris.
> -----Original Message-----
> From: Assaf Arkin [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, January 20, 2000 8:11 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Vendor Challenge
>
> 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".
===========================================================================
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".
