Steve -
Some of this depends on your app server.
Depending on the app server you're using the SSB's may be stored in the
equivalent of a session context in the ejb container. I know that managing
failover among app servers gets more complex if the app servers have to
synch a great deal of SSB replication - different servers handle it
differently. In other words, you likely haven't reduced the overall memory
requirements.
And you've likely added overhead related to serializing and unserializing
the bean info as it moves between the sevlet and ejb containers.
My approach is this:
- Don't run from ghosts. That is, don't refactor until you've actually
enountered a problem - unless there are good other reasons to refactor.
- Memory is much cheaper than development time. Have them load the box as
high as possible before re-writing.
Another approach:
If you're concerned about carrying session related stuff in the user
session, store it in a database keyed by a Session ID. I've seen this done
successfully. You probably don't need all that information on every page -
so some of it can likely be stored in the database and pulled back when
needed (if ever). This can be done via a session object, a SSB or even an
entity bean (primary key = Session ID). I wouldn't write this unless I
actually ran into a performance problem - but I'd design to make sure it
was easy to implement if I needed to.
It might be useful to explore the creation of Struts "model" classes to
facilitate persisting of session information via a jdbc connection. Maybe
this could become a standard Model class that could be subclassed for
particular implementations.
FWIW -
Kevin
Steve Earl <[EMAIL PROTECTED]> on 04/23/2002 04:38:27 AM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Where is it best to populate default form bean collections et
c?
Guys,
A bit off-topic but opinions appreciated...
I've recently changed an app I'm working on to no longer hold forms on the
session but instead store them within a stateful session bean. Prior to
displaying any jsp I've then got dedicated action classes which retrieve
the
correct form from the ssb and place it into the request.
We decided to do this because the application is likely to result in a
large
amount of data being held through a user session. In addition the app is
multi-frame (I know - try telling the client it's a pain in the arse...). I
was under the impression that storing forms on the session would mean that
a
bloated session object would have to be sent to each frame within the
application (sometimes we have 8 or more on a page) and this would be
detrimental to performance. Basically I thought the idea was to avoid
placing too much data on the session if at all possible. I appreciate that
a
remote call to a ssb is not likely to be the most rapid access method but I
was concerned about running a multi-framed app with a large session object.
Can someone tell me if my opinion is correct or have I just changed a whole
shedload of classes, config files etc for no reason....!
go on, make my day!
steve
__________________________________
Steve Earl
InfoGain Limited
-----Original Message-----
From: Galbreath, Mark [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 22, 2002 9:02 PM
To: 'Struts Users Mailing List'
Subject: RE: Where is it best to populate default form bean collections
et c?
Yep - the init method of the servlet or static initializers are better.
Mark
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 22, 2002 3:28 PM
To: Struts Users Mailing List
Subject: RE: Where is it best to populate default form bean collections
et c?
I generally use a "static initializer" (also called an anonymous block) for
this stuff.
For example state codes could be done in a static class called States.java
public static class States {
private HashMap statesMap;
public HashMap getStates() {
return this.statesMap
}
public void setStates(HashMap states)
{
this.statesMap = states;
}
// Begin anonymous block for initialization
{
this.setStates(this.initializeStates());
}
private HashMap .initializeStates() {
HashMap states;
// put code here to initialize the hashmap via jdbc, xml parsing,
whatever...
return states;
}
}
Then the first time you reference the States class it is automatically
initialized. After the first time it is referenced, everything is cached.
"Thinh Doan" <[EMAIL PROTECTED]> on 04/22/2002 03:24:35 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:
Subject: RE: Where is it best to populate default form bean collections et
c?
We did it using an init servlet, run when the app gets loaded and stay in
app. scope.
Thinh
-----Original Message-----
From: Schneider, Eric [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 22, 2002 1:13 PM
To: 'Struts Users Mailing List'
Subject: RE: Where is it best to populate default form bean collections
et c?
I'm curious about this too. How are other developers initializing
application scope resources?
For example, maybe a list of cities or states. Things that end up in
numerous forms that don't change often, but are large enough to be stored
in
the database. These kind of things don't seem appropriate in a user's
session.
Thanks,
eric.
> -----Original Message-----
> From: Hoang, Hai [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 1:40 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Where is it best to populate default form bean
> collections
> et c?
>
>
> I've been using the Action classes to load the required data
> for the form
> and place it under session object if the data does change
> often and the
> dropdown is being used repeatedly. This way, you don't have
> to when back to
> the database everytime. The draw back to this technique is that the
> scalability issue. Just be sure to remove these collections from the
> session object when you are done.
>
> I am very much interest in seeing other techniques being used.
>
> -----Original Message-----
> From: Rick R [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 22, 2002 12:30 PM
> To: [EMAIL PROTECTED]
> Subject: Where is it best to populate default form bean
> collections etc?
>
> Sorry if I'm not to clear here but I'm really curious about
> the best design
> principle to use under struts in the following situation...
>
> Say you want to set up a jsp form and on the form you have
> several select
> elements. Each set of select elements is created dynamically
> from a query to
> the database. I have a corresponding form bean that goes with
> this page.
>
> The question I have is it ok to set up the default select
> lists inside the
> form bean by calls to some other business logic? For example...
>
> private dogsArray = business.getDogsArray();
>
> then your normal set and get method.
>
> I tend to thin this probably isn't a good idea and it would
> be best to have
> some action class create the array and then call the
> appropriate form bean
> set method. I'm not sure though.
>
> Then what about when the form is reset, I take it you just
> make another call
> to the default action that sets up your form bean? I noticed
> in some of the
> examples they have a reset() method inside the form beans
> which goes and
> sets the fields to default values. This is why I began
> questioning the best
> practices, since if I follow that route than I really would
> have to call
> some business logic to populate the String[] arrays for the
> select options
> in the form beans.
> Hopefully I'm making some sense.
>
> Thanks for any advice.
>
> Rick
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
**********************************************************************
This message, including any attachments, contains confidential information
intended for a specific individual and purpose, and is protected by law.
If
you are not the intended recipient, please contact sender immediately by
reply e-mail and destroy all copies. You are hereby notified that any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.
TIAA-CREF
**********************************************************************
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
