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