struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: [SURVEY] Session-based forms vs. request-based forms
Date Wed, 02 Oct 2002 16:25:26 GMT
I do believe that indeed the accepted wisdom is to make use of request
instead of session wherever you can (though use common sense - if you can
cache stuff that doesnt change much do so!).

Alas in my case, I simply didnt have time to do it the hard way and am using
session for almost all of my forms :-(
(Lot of back and forthing on the same form , showing this and hiding that
etc..., to meet business requirements - not to mention diverting off to edit
other forms (reachable from many places) and coming back afterward to finish
the first (using records created or edited from the second (which itself may
have many such diversions ad infinitum...))... it would be an absolute
nightmare with request scope only (for me anywhow. Some of the more
experienced strutters could probably make a go of it))

-----Original Message-----
From: Taylor, Jason []
Sent: Wednesday, October 02, 2002 23:38
To: 'Struts Users Mailing List'
Subject: [SURVEY] Session-based forms vs. request-based forms

Right now, I'm converting my session-based forms to request-based forms
because I'm trying to minimize my use of the session object.

The reason is that I found out that when my container runs in clustered
mode, it serializes the attributes of the session object and broadcasts the
updates across the network to one or two machines with backup sessions
anytime the setAttribute() and removeAttribute() methods are invoked.
Therefore, there seems to be a lot more overhead in a cluster than
standalone in terms of session serialization due to additional network I/O
and deserialization on the backup session servers.

Would anyone care to share their wisdom on the subject of request vs.
session scope for forms in a clustered environment?  Am I right that
session-based forms should be avoided unless required by performance or
business logic concerns?  Any thoughts would be helpful.

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

View raw message