struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clóvis Yutaka Harada" <>
Subject RE: business logic beans
Date Tue, 30 Oct 2001 21:34:20 GMT
First, you can do other things with your form beans. Only take care of the
reserved methods, see javadoc for ActionForm.

There is not a best answer to your other questions.
Just remember this:
1. It seems that the form needs to have different time-out than the session,
not the business logic bean. Thinking this way can give you a better answer.

2. You can put you bean into a session attribute. But take care of what you
are putting in the session. Anything you put in the session remains in
memory until session times-out or you explicitly removes it or ends the
session. This can become a performance problem and it will be worse in a
distributed environment with load balance without session-affinity. As a
suggestion, you can put only the primary key in a session attribute or send
it to the browser as a hidden field.
   If the load balancing policy replicates all session in the memory of all
web servers, than it´s not a good idea to put things in session without a
good reason. Even if putting an object with setAttribute() is only creating
2 references (and possibly alocating memory for a new entry) in the session
structure. If that object contains a big structure inside, for example, a
collection, if you change one element of the collection you will need to
make this change available to all servers. To do so, you will reassign the
collection to the session. Internally your load-balanced servers will
replicate the entire collection again to all server (and you changed only
one entry).
   If the application runs on a single server, memory should also be a

For a high traffic site, depending on your configuration (clusters,
tiers,..) and requirements (performance, availability, scalability,...)
sometimes you will keep only the key (in the session, as cookie, as hidden
fields,...) and retrieve all data from the persistent storege at every
request (using some caching mechanism). This give you good scalability
(almost every module can be replicated) but this also increase latency when
few requests are arriving.

For a low traffic, this is not an issue and you can put your data in the

-----Original Message-----
From: Andy Noble []
Sent: Tuesday, October 30, 2001 3:05 PM
To: Struts User List
Subject: business logic beans

Hi all,

As I understand it, the FormBean should just have getters and setters with
no busines logic. So I've created a separate business logic bean.
What I would like help on is the best place to put this bean so that it
survives beyond a request.

I'm currently working with a 3 layered architecture, of presentation,
business logic and database layers. At the moment when a user wants to edit
a record, the following happens:

1. Action class invoked, which requests data from a business logic bean (in
business logic layer).
2. business logic bean delegates to db bean (in db access layer) which
retrieves data from database.
3. business logic bean takes data from db bean and populates a FormBean with
displayable/editable data. The database primary key references etc remain in
the business logic bean.
4. The JSP is populated from the FormBean by struts and served up to the
5. The user edits and posts.

Now what I would like to happen is this:
6. The Action class takes updated FormBean data and updates (or recreates if
request scoped only) business logic bean
7. business logic bean validates and passes to db layer
8. db layer updates database.

>From the above, I can think of three options :

1. If the business logic bean survives beyond the initial request, it would
need to have session scope. I'm not clear on where to store this bean
though, so I can reference it on the second request. Would it be sensible to
make it an attribute of the FormBean, or is there some other collection it
can become a member of? Is there a way to give the bean a timeout separate
from the session?

2. An alternative would seem to be to keep everything request oriented and
send everything to the user, with db keys in hidden form fields and deal
with the lot when it is submitted in a second request.

3. The third option would be a mix of the first and second. Keep only the db
keys in session parameters, but send the bulk of the data in the form, and
match and process the two upon receipt of the second request.

Does anyone have any advice on the best approach, pros and cons, and indeed
if these are valid approaches?
Any help appreciated.

Thanks in advance

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message