Chris Raber wrote:
>
> 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?
Yes.
arkin
>
> -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".
--
----------------------------------------------------------------------
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".
