Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
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
RE: Frames, concurrency, and EJB Stateful Session beans - a problem.
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
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
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 MalksSun Java Center Enterprise Java Architect703.208.5794
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
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). 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 broughtto my attention that there were some business tier coupling and EJB issues beingdiscussed, so I thought I'd make a few quick comments.Looking back over the thread, there is a mention of using a handler class asbasically a client-side business abstraction, which I think makes great sense.It reduces the coupling between tiers and provides a nice place for things likeremote lookups, caching, synchronization, exception type translation, etc...About a month ago, we did a beta release of a set of J2EE patterns (availableat: 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 beinterested to check it out. There is a related Service Locator pattern thatdeals 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. Updatedversions will be available soon, including lots of source code. If you havesuggestions, we'd love to hear them. Also, there is a discussion list forrelated conversation(http://archives.java.sun.com/archives/j2eepatterns-interest.html). Hope thisproves useful to you.Thanks,Dan"Hines, Bill" wrote:
Brian,Disclaimer: I'm new to EJB and still trying to understand when to usestateful/stateless session beans.Given that, I found your situation interesting. First I'll try to help youif I can. There is an article in the February 2001 WebSphere Advisor by TonyHigham, on page 10, titled "The Reality of EJB". It should be available ontheir web site. He talks about problems like yours and recommends anapproach where you use stateless beans but an alternative state-handlingmechanism such as HttpSession to hold the user's data. Will that sort ofthing work for you? It sounds more light-weight than stashing the wholesession bean and/or accessor JavaBean with synchronized methods into thesession. There are also some good patterns for using session beans in theIBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphereApplication Server", which is available for download o!
n the IBM Redbookssite. You might find some ideas there.Now that I've tried to help, if you could, explain your aversion tostateless and why they won't work for you in this situation, so that I canlearn more.Thanks, your questions and contributions here are very useful to me.Bill HinesSun Certified Java ProgrammerHershey Foods Corp-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:09 AMTo: [EMAIL PROTECTED]Subject: Frames, concurrency, and EJB Stateful Session beans - aproblem.I'm having a design problem with my system, which is not really Strutsspecific, but since there are a lot of EJB users here, I thought I'dthrow it on this list
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Bill -- I think the important design point to make, is that you want your business logic (including rules of behavior, state machine, etc) to be encapsulated within the EJB tier. This makes for tidier code and a more elegant design, and also makes your code more client-neutral. One of the scenarios you describe is to use stateless session beans, and store user state at the servlet level. While I haven't read the article, and while I will give it the benefit of the doubt that there might be some hidden benefit to that, still I would discount it as a design methodology -- it seems to needlessly spread your business logic across two completely separate subsystems with completely separate programming paradigms (that is, the Servlet level and the EJB level). If the only "problem" that this design is meant to solve is the concurrency issue which started this thread, then I think the solution I ended up on is a better one -- a simple wrapper class around the session bean which adds syncronization to the methods. Hopefully this sheds some light on your follow up question, "why the aversion to stateless". I have users, they log in to the system, and they perform actions against a database, and I need to be sure that they can only perform the actions they are authorized to perform, and only against the data that they are authorized to access. So I have stateful session beans for the users; the only "state", really, is "who is this user?" (obtained from a "logon" method, which is the only method allowed to be executed right after creation). The rest of the methods check who the current user is, and use entity beans to get/set the appropriate data. At the web tier (Struts and JSP), I basically have a library of Struts actions and custom JSP tags which pretty much just duplicate the method names in the session bean, passing parameters to the EJB tier and packaging the return values as javabeans for the JSP to display. So, at the web tier, there really is no "state" at all, except for a reference to the user's EJB session bean. Stateful session beans are the way to go with my application, it keeps the meat of the system all in one tier (EJB), and keeps my web tier very simple (it wouldn't be hard, for example, for me to re-implement my Struts actions in some other framework, since they are just lightweight pass-throughs anyway). Regards, Bryan 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
RE: Frames, concurrency, and EJB Stateful Session beans - a problem.
Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through the JavaBean? --Abraham -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 8: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
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Thanks, That proposal would probably work, but it might be a little over-complicated (although I am starting to suspect that every solution is going to be yucky). I think I couldn't do your idea with just a simple bean with a simple syncronized getter method; instead, the wrapper bean would have to have all of the same method signatures as the session bean, and pass through all the calls (doing syncronization first). What I'm leaning towards right now, is finding some kind of "per-user" syncronization, which I can "lock" at the start, and "unlock" at the end, of every one of my Action.perform() methods. I can probably do this with a simple class, with two static methods -- "lock" and "unlock" -- and it will take as a parameter the current user's "session" object (Servlet session, that is), so that the locks are per-user, rather than global. Comments before I dive in the deep end? Thanks, Bryan Abraham Kang wrote: Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through the JavaBean? --Abraham -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 8: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
RE: Frames, concurrency, and EJB Stateful Session beans - a problem.
I think that's the way you'd want to go. Essentially you're sharing the reference to the EJB across mutliple threads, which kind of violates the "1 client - 1 instance" doctrine of stateful session beans (kind of in that it's the same logical client, but two physical instances of client, if you will). You can have this same problem within multithreaded applications as well. If you wrap the reference within a javabean that synchonizes access, and share this bean in session scope you should be ok. -Original Message- From: Abraham Kang [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 11:07 AM To: [EMAIL PROTECTED] Subject: RE: Frames, concurrency, and EJB Stateful Session beans - a problem. Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through the JavaBean? --Abraham -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 8: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
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Now that I think about it, perhaps a solution to this would be a great general-purpose configuration feature for Struts. On a per-web-application level (e.g. in struts-config.xml), there might be an option such as: syncronize_requests = x where x might be: none - the default -- the current Struts behavior session - syncronize requests on a per user (per-session) basis (but allow concurrent access from different users) application - syncronize all requests, globally This would be to support whacko frameworks like EJB, whereby you can't have concurrent access to Stateful Session Beans. (in that scenario I would use "session" rather than "application" syncronization). Note also (and this is very important) -- that if this were to be a general-purpose Struts mechanism, I would need to be able to tie into it from my custom tag library, as well as my Action classes, since tags might also access an EJB bean. Regards, Bryan
RE: Frames, concurrency, and EJB Stateful Session beans - a problem.
I usually try to stay far away from doing lock/unlock type things with threaded access - really testing it can get too hairy, and problems tend to be hard to trace. The practice we use here for EJBs is thus (it's actually not too hard to do, and hides the fact that you're using EJBs from the front end). Ixxx.java - interface defining business methods xxxBean.java - implementation code: xxxBean implements SessionBean, Ixxx xxxHome.java - standard Home interface xxxRemote.java - remote interface, extends EJBObject, Ixxx xxxHandler.java - wrapper class, implements Ixxx The JavaBeans (and JSPs in some cases - no, we're not using Struts (yet)) use the xxxHandler classes for all access. The xxxHandler actually does to the lookup, home create, portable narrow, and delegates all calls to the EJB. The code is so straightforward it could really be generated (of course, we don't do that). Since everything runs off of the Ixxx interface, the compiler will catch if you change signatures in one place and not the other. And your Remote interface is empty, since it just "joins" the EJBObject and Ixxx interfaces. Food for thought, there are many other ways to do this. --jason -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 11:33 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a problem. Thanks, That proposal would probably work, but it might be a little over-complicated (although I am starting to suspect that every solution is going to be yucky). I think I couldn't do your idea with just a simple bean with a simple syncronized getter method; instead, the wrapper bean would have to have all of the same method signatures as the session bean, and pass through all the calls (doing syncronization first). What I'm leaning towards right now, is finding some kind of "per-user" syncronization, which I can "lock" at the start, and "unlock" at the end, of every one of my Action.perform() methods. I can probably do this with a simple class, with two static methods -- "lock" and "unlock" -- and it will take as a parameter the current user's "session" object (Servlet session, that is), so that the locks are per-user, rather than global. Comments before I dive in the deep end? Thanks, Bryan Abraham Kang wrote: Hi Bryan, Can you put the stateful session bean within a JavaBean with synchronized methods so that all access to the stateful session bean is through the JavaBean? --Abraham -Original Message- From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 05, 2001 8: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
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
Good grief -- what a twistly little maze of passages, all alike (or was that, a maze of twisty little passages, all alike?) Thanks for laying out those extra thoughts. I think you're right that the GP approach puts too much of a burden on the client to use it correctly. I still maintain that a REALLY GP approach (that is, built in to Struts, and activatable with a single config option) would be useful, but I haven't the time for that right now. I think I'll go the xxxHandler route. Thanks again, Bryan Jason Pringle wrote: 168B2A5F6A99D4119E28C7C9CA80DE35D0@GIBRALTAR">Yup, that's where I would put the synchronization. At first guess I would think this would be simpler than the general purpose approach, because you've placed all responsibility for synchronization in a distinct spot - the xxxHandler. Any user of the handler doesn't have to even think about the fact that it's synchronized or thread-safe*. In the GP approach, safety depends on both the implementation of the locking system, and the correct usage of the locking system by participants. You'd also want to think about locking specific resources, not just locking the whole servlet - it gets deeper and deeper. There may be issues with locking and forwarding between pages (nested locks?). What about error processing - deadlocks can come into play. Finally, from the performance standpoint, general practice is to limit synchronization to the minimum time needed. In this case that's access to the EJB. If you lock at the servlet level you're unnecessarily restricting throughput.Note that a limitation of this approach is that no ordering is imposed on access serialization. IE - if you have two frames accessing the EJB simultaneously, the actions of one cannot depend on the actions of the other because you can't guarantee which frame is going to attempt access first. If order of execution is important, then you'll need some other type of component broker in the mix.--jason* ok, it's not totally thread-safe unless you make the handler a singleton, which is likely NOT the desired behavior (ie - you want different users to have their own instances). So you do have to guarantee that no two instances of xxxHandler ever reference the same xxxEJB instance. This is inherent in the design as long as you restrict access to EJBs to using the xxxHandler mechanism.-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 12:15 PMTo: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java?That seems elegant; I had never thought of implementing a separate handler class for my EJB's, although it's always been on my "to-do" list to try having Bean and Remote implement a common interface (just haven't gotten around to it yet). From my standpoint (and the problem I'm trying to solve), I'm not sure that adding the "xxxHandler" class with syncronization is going to be any easier for me than a general-purpose "Servlet session syncronization" utility, since I am at ground zero with either approach. They both have appeal. I will stew on this over lunch today and see where that leads me.Thanks for the input,BryanJason Pringle wrote:168B2A5F6A99D4119E28C7C9CA80DE35CE@GIBRALTAR" type="cite">I usually try to stay far away from doing lock/unlock type things withthreaded access - really testing it can get too hairy, and problems tend tobe hard to trace.The practice we use here for EJBs is thus (it's actually not too hard to do,and hides the fact that you're using EJBs from the front end).Ixxx.java - interface defining business methodsxxxBean.java - implementation code: xxxBean implements SessionBean, IxxHome.java - standard Home interfacexxxRemote.java - remote interface, extends EJBObject, IxxHandler.java - wrapper class, implements IxxxThe JavaBeans (and JSPs in some cases - no, we're not using Struts (yet))use the xxxHandler classes for all access. The xxxHandler actually does tothe lookup, home create, portable narrow, and delegates all call! s to theEJB. The code is so straightforward it could! really be generated (ofcourse, we don't do that). Since everything runs off of the Ixxx interface,the compiler will catch if you change signatures in one place and not theother. And your Remote interface is empty, since it just "joins" theEJBObject and Ixxx interfaces.Food for thought, there are many other ways to do this.--jason-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:33 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - aproblem.Thanks,That ! proposal would probably work, but it might be a little ove!r-complicated (although I am starting to suspect that every solution is going
Re: Frames, concurrency, and EJB Stateful Session beans - a problem.
I implemented your solution -- xxxHandler.java for my stateful session bean, and a new interface which the bean, remote interface, and handler all implement (or extend). Also added EJB creation, and method pass-through (with syncronization) to the handler class. Lastly, changed all my Struts code to use the handler and the new interface, instead of the old remote interface. Result - works like a champ! Frameset problem solved. Took about one hour to implement. Thanks again, Bryan Jason Pringle wrote: 168B2A5F6A99D4119E28C7C9CA80DE35D0@GIBRALTAR">Yup, that's where I would put the synchronization. At first guess I would think this would be simpler than the general purpose approach, because you've placed all responsibility for synchronization in a distinct spot - the xxxHandler. Any user of the handler doesn't have to even think about the fact that it's synchronized or thread-safe*. In the GP approach, safety depends on both the implementation of the locking system, and the correct usage of the locking system by participants. You'd also want to think about locking specific resources, not just locking the whole servlet - it gets deeper and deeper. There may be issues with locking and forwarding between pages (nested locks?). What about error processing - deadlocks can come into play. Finally, from the performance standpoint, general practice is to limit synchronization to the minimum time needed. In this case that's access to the EJB. If you lock at the servlet level you're unnecessarily restricting throughput.Note that a limitation of this approach is that no ordering is imposed on access serialization. IE - if you have two frames accessing the EJB simultaneously, the actions of one cannot depend on the actions of the other because you can't guarantee which frame is going to attempt access first. If order of execution is important, then you'll need some other type of component broker in the mix.--jason* ok, it's not totally thread-safe unless you make the handler a singleton, which is likely NOT the desired behavior (ie - you want different users to have their own instances). So you do have to guarantee that no two instances of xxxHandler ever reference the same xxxEJB instance. This is inherent in the design as long as you restrict access to EJBs to using the xxxHandler mechanism.-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 12:15 PMTo: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java?That seems elegant; I had never thought of implementing a separate handler class for my EJB's, although it's always been on my "to-do" list to try having Bean and Remote implement a common interface (just haven't gotten around to it yet). From my standpoint (and the problem I'm trying to solve), I'm not sure that adding the "xxxHandler" class with syncronization is going to be any easier for me than a general-purpose "Servlet session syncronization" utility, since I am at ground zero with either approach. They both have appeal. I will stew on this over lunch today and see where that leads me.Thanks for the input,BryanJason Pringle wrote:168B2A5F6A99D4119E28C7C9CA80DE35CE@GIBRALTAR" type="cite">I usually try to stay far away from doing lock/unlock type things withthreaded access - really testing it can get too hairy, and problems tend tobe hard to trace.The practice we use here for EJBs is thus (it's actually not too hard to do,and hides the fact that you're using EJBs from the front end).Ixxx.java - interface defining business methodsxxxBean.java - implementation code: xxxBean implements SessionBean, IxxHome.java - standard Home interfacexxxRemote.java - remote interface, extends EJBObject, IxxHandler.java - wrapper class, implements IxxxThe JavaBeans (and JSPs in some cases - no, we're not using Struts (yet))use the xxxHandler classes for all access. The xxxHandler actually does tothe lookup, home create, portable narrow, and delegates all call! s to theEJB. The code is so straightforward it could! really be generated (ofcourse, we don't do that). Since everything runs off of the Ixxx interface,the compiler will catch if you change signatures in one place and not theother. And your Remote interface is empty, since it just "joins" theEJBObject and Ixxx interfaces.Food for thought, there are many other ways to do this.--jason-Original Message-From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]Sent: Thursday, April 05, 2001 11:33 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: Frames, concurrency, and EJB Stateful Session beans - aproblem.Thanks,That ! proposal would probably work, but it might be a little ove!r-complicated (although I am starting to suspect that every solution is going to be yucky). I
