Bryan,
Bryan Field-Elliot wrote:
> Thank you Dan --
>
> 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).
This is why they call it a pattern, isn't it ;-)
Glad your problem is solved.
> 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); }
BTW, are you throwing this remote exception back into the presentation
tier framework code? If one goal of your handler class (ie: business
delegate) is to reduce coupling by proxying and hiding the
implementation details of EJB, then you should consider converting
system-level exceptions, such as RemoteException into
application-friendly exceptions b4 sending them back to the pres tier
framework code.
>
> }
>
> 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.
I'll pass this along to the appropriate folks.
Thanks,
Dan
>
>
> Thanks,
>
> Bryan
>
>
>
> Dan Malks wrote:
>
>> 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
>>
>>
>>
>>
--
Dan Malks Sun Java Center
Enterprise Java Architect 703.208.5794
