struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: Semi-OT: Saving state when using EJB Session Beans and Struts
Date Tue, 02 Mar 2004 22:32:45 GMT
OK, go for it then. I think the only thing to be really concerned about 
is memory availability. If you're storing stuff in the user's session 
and maintaining SSBs, memory usage might build up quickly.

Plus, depending on how critical your application is, you might have to 
worry about failure wiping out your SSBs before they're done. If you had 
stateless SBs, it wouldn't be a problem with fail-over support and a web 
farm :)

On 03/02/2004 08:58 PM Smith, Darrin wrote:
> Currently the design is to cache the instances of the Stateful Session
> beans, and do that in the Actions themselves.  One SSB per Action. The
> reason for the SSB is primarily for the transaction support (online
> ordering) but also because addition EJB use will be needed in the future
> anyway (interfacing with an existing system that will eventually use Message
> Driven Beans to communicate...using simply JDBC to populate a "posting"
> table now).
> 
> You are correct in that the web interface is for an existing application
> (the one that will eventually talk through a message queue...but today only
> works with posting tables...another reason why transaction support is a good
> thing).
> 
> I guess it might make sense to keep the intermediate information (the lists
> that can be ordered, the patients the items can be order for, etc.) in the
> servlet's session as you say.  The SSB's though would still be used though
> to get the intermediate data to be passed back and held in the servlet.  
> 
> Example...the user needs to get a list of patients that the order will be
> applied to.  The RetrievePatientsAction gets invoked, and it in turn creates
> a SSB (if one isn't already cached) to perform the actual business logic
> needed to do this step. 
> 
> Using that data, a JSP is created and the user selects a patient, and then
> requests a list of items applicable to that patient. Then the request to
> retrieve that information is passed in and a similar process occurs to the
> one above.
> 
> Finally, all of the information is available, and an order is place that
> goes through a similar process.
> 
> 
> This is a semi-contrived example of course but it is an example of what the
> thinking is.
> 
> 
> 
> -----Original Message-----
> From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
> Sent: Tuesday, March 02, 2004 12:21 PM
> To: Struts Users Mailing List
> Subject: Re: Semi-OT: Saving state when using EJB Session Beans and
> Struts
> 
> 
> It's difficult to know what scenario you are talking about here.
> 
> I assume you mean to cache the EJBs in the user's servlet session, so
> you will have several remote EJBs in there depending on how many
> different actions the user has accessed.
> 
> It sounds like you need to do this to allow transaction management
> across a group of data operations?
> 
> I would not do it by caching the EJBs at all, or having stateful session
> beans. I would keep my actionformbean in the user's servlet session
> instead, accumulating the data over several http requests and then
> marshall the whole collection of data across to the EJB session in one.
> 
> Struts is good at that. I expect you'd give yourself more headaches than
> it's worth, trying to collect the user's session data in the EJB layer.
> 
> It sounds like you are writing a web interface for an already existing
> client-server app.
> 
> 
> On 03/02/2004 03:42 PM Smith, Darrin wrote:
> 
>>Thanks for the reply!
>>
>>That is kind of what is going on already.  The Action's act as the local
>>Java class talked about in the Business Delegate Pattern that create and
>>cache the Stateful Session Bean (a different one per Action).  They (the
>>Actions) then use the Session Bean's business logic. This is done in a
>>standard way though where each Session Bean will implement an interface
> 
> that
> 
>>is common to all of the other Session Beans in the application. This way
>>each action simply calls a factory and based on the way the factory is
>>called, a Stateful Session Bean for that type of action is returned, then
>>cached in the Action.  All actions then can make the submit(...),
>>inspect(...), etc. calls common to all types of Session Beans (but
> 
> performed
> 
>>differently by each one).
>>
>>The question is though, for these actions, shouldn't they keep session
> 
> state
> 
>>that will match the Stateful Session Beans?  Typically, I know you want
> 
> have
> 
>>your Model hold Session state while your client holds request state, but
> 
> in
> 
>>this case, where the Action needs to remember the cached Session Bean,
>>doesn't it seem to make sense to mark the Action as session scope in the
>>struts config file as well?
>>
>>  
>>
>>-----Original Message-----
>>From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
>>Sent: Monday, March 01, 2004 5:35 PM
>>To: Struts Users Mailing List
>>Subject: Re: Semi-OT: Saving state when using EJB Session Beans and
>>Struts
>>
>>
>>On 03/01/2004 05:47 PM Smith, Darrin wrote:
>>
>>
>>>In short, the Actions will be calling various Stateful Session Beans to do
>>>the actual work.  These are used for various reasons with the main one
>>
>>being
>>
>>
>>>their built-in transaction support (online orders...need to be either
>>>done...or not done). How should state be handled and at what level
>>>(page...request...session...) in the upstream struts portion? 
>>
>>
>>Hmmm. Thought someone more knowledgeable would answer this, and was 
>>waiting with interest myself. Oh well. Without too much experience with 
>>EJBs myself, I can say a couple of things: the gurus say 'use the 
>>business delegate pattern with an EJB session facade'. Secondly, it 
>>depends heavily on what your stateful session beans are holding as 
>>state. Care to name something?
>>
>>Adam
> 
> 
> 


-- 
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message