As I emailed at around midnight last night, I have everything taken care of, using Jason Pringle's pattern. It's probably very similar to the Business Delegate pattern you describe (which I will read today). Basically I implemented a handler class for the Stateful Session Bean, which contains a duplicate of all of the bean's remote interface methods. In it's constructor, I create a private instance of the "real" bean. And in all of the methods, I'm just passing through the parameters to the "real bean" and returning it's return values, to the client. In this case, the "client' is always a Struts Action or a custom JSP tag.
All of these methods are wrapped in a simple "syncronized" statement to the bean instance:
String businessMethod1(int param1, int param2) throws RemoteException {
syncronized(theBean) { return theBean.businessMethod1(param1, param2); }
}
That wasn't so bad, really, and it solved my concurrency problem completely. For good measure I also implemented the "common business interface" pattern (or whatever it's properly called), in which I have a single interface defining my business methods, which is extended (or implemented) by the RemoteInterface, the Handler, and the actual Bean. This makes for tidier code but wasn't really germaine to my syncronization problem.
Lastly, you say "if I have any suggestions, you'd love to hear them". Well here's a big suggestion -- an EJB container should, at the deployer's option, syncronize concurrent calls to Stateful Session Beans rather than simply reject outright the second one. As a developer (or deployer), I should be able to choose whether I want an exception, or blocking, in the case of Stateful bean concurrency. Either way, I believe EJB's design goals are met, which is to prevent concurrency. With that as an amendment to the spec (EJB 2.0), I wouldn't have to write these silly wrappers.
Thanks,
Bryan
Dan Malks wrote:
[EMAIL PROTECTED]">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 o! n 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, genera! l-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
