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".
