Thanks again,
Bryan
Jason Pringle wrote:
168B2A5F6A99D4119E200008C7C9CA80DE35D0@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-----So in your scenario (as a proposed solution to my problem), I would add syncronization code to xxxHandler.java?
From: Bryan Field-Elliot [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 12:15 PM
To: [EMAIL PROTECTED]
Subject: Re: Frames, concurrency, and EJB Stateful Session beans - a probl em.
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,
Bryan
Jason Pringle wrote:168B2A5F6A99D4119E200008C7C9CA80DE35CE@GIBRALTAR" type="cite">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 call! s 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
ove!
r-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 Kan! g wrote:Hi Bryan,
Can you put the stateful session bean within a JavaBean withsynchronizedmethods 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
