All,
Sorry to jump in late on this.
Am not monitoring this list real consistently at the moment, but it was brought
to my attention that there were some business tier coupling and EJB issues being
discussed, so I thought I'd make a few quick comments.

Looking back over the thread, there is a mention of using a handler class as
basically a client-side business abstraction, which I think makes great sense.
It reduces the coupling between tiers and provides a nice place for things like
remote lookups, caching, synchronization, exception type translation, etc...

About a month ago, we did a beta release of a set of J2EE patterns (available
at: http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/),
which includes just such a pattern...it's called the Business Delegate pattern,
and describes these issues among others, so I thought some folks might be
interested to check it out. There is a related Service Locator pattern that
deals with hiding the impl details of remote lookups.

The pattern descriptions have changed quite a bit even from the beta release,
based on lots of quality feedback we've received from the community. Updated
versions will be available soon, including lots of source code. If you have
suggestions, we'd love to hear them. Also, there is a discussion list for
related conversation
(http://archives.java.sun.com/archives/j2eepatterns-interest.html). Hope this
proves useful to you.

Thanks,
Dan

"Hines, Bill" wrote:

> Brian,
>
> Disclaimer: I'm new to EJB and still trying to understand when to use
> stateful/stateless session beans.
>
> Given that, I found your situation interesting. First I'll try to help you
> if I can. There is an article in the February 2001 WebSphere Advisor by Tony
> Higham, on page 10, titled "The Reality of EJB". It should be available on
> their web site. He talks about problems like yours and recommends an
> approach where you use stateless beans but an alternative state-handling
> mechanism such as HttpSession to hold the user's data. Will that sort of
> thing work for you? It sounds more light-weight than stashing the whole
> session bean and/or accessor JavaBean with synchronized methods into the
> session. There are also some good patterns for using session beans in the
> IBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere
> Application Server", which is available for download on the IBM Redbooks
> site. You might find some ideas there.
>
> Now that I've tried to help, if you could, explain your aversion to
> stateless and why they won't work for you in this situation, so that I can
> learn more.
>
> Thanks, your questions and contributions here are very useful to me.
>
> Bill Hines
> Sun Certified Java Programmer
> Hershey Foods Corp
>
> -----Original Message-----
> From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2001 11:09 AM
> To: [EMAIL PROTECTED]
> Subject: Frames, concurrency, and EJB Stateful Session beans - a
> problem.
>
> I'm having a design problem with my system, which is not really Struts
> specific, but since there are a lot of EJB users here, I thought I'd
> throw it on this list for comments --
>
> My business logic is all implemented in a Stateful EJB Session bean. All
> Struts users get one instance of the session bean, whose reference is
> stored in the Servlet's Session scope.
>
> All of my Struts actions are simple; they take data from the user
> (usually in ActionForms), pass them to some method in the EJB Session
> bean, and store the results in beans for the JSP page to render.
>
> However, my design calls for a few places where there is a frameset, and
> in another place, where two browser windows open up showing two
> different views. The problem here, is that EJB requires that a Stateful
> Session bean have only one thread of execution within it (e.g. no
> concurrency). So, when two different Struts actions (or custom tags) try
> to invoke a method on the same EJB Session bean reference at the same
> time, one of them will fail with an exception thrown by the EJB
> container (in my case, jBoss).
>
> Can anyone recommend an easy, general-purpose solution to this problem?
> (Please don't say, "switch to stateless session beans"). I suppose I
> need to syncronize access to the EJB bean from the client (and, in this
> case, the client is Struts), but I'm not sure how to do this quickly and
> elegantly.
>
> Comments would be appreciated,
>
> Bryan

--
Dan Malks                            Sun Java Center
Enterprise Java Architect            703.208.5794


Reply via email to