RE: Frames, concurrency, and EJB Stateful Session beans - a probl em.

["Deadman, Hal" <ha...@tallan.com>]

I like this. I have seen the business interface idea described before but I
like the handler as a way to hide EJB calls from the front-end code. Do you
typically access entity beans from stateless session beans or do you call
entity beans directly from the front end? Do you have business interfaces
and handler classes for both entity beans and session beans? 

>From the original post, why not store state somewhere else besides the
stateful session bean? I haven't run into a reason to use stateful session
beans in a web application where there are plenty of other places to store
state (cookies, session, db). I would be interested to hear when people have
found them to be useful. 

Hal

> -----Original Message-----
> From: Jason Pringle [mailto:JasonP@captura.com]
> Sent: Thursday, April 05, 2001 2:41 PM
> To: 'struts-user@jakarta.apache.org'
> Subject: RE: Frames, concurrency, and EJB Stateful Session beans - a
> probl em.
> 
> 
> 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:bryan_lists@netmeme.org]
> Sent: Thursday, April 05, 2001 11:33 AM
> To: abrahamk@infogain.com
> Cc: struts-user@jakarta.apache.org
> 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:bryan_lists@netmeme.org]
> >> Sent: Thursday, April 05, 2001 8:09 AM
> >> To: struts-user@jakarta.apache.org
> >> 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
> >> 
> >> 
> >> 
>