Adrian Beech wrote:
Hi all,
A work colleague mentioned on Friday it would be better to place objects
(beans and the like) which had been created in a servlet into the request
context when exposing them to the JSP. To date all the code I've written
stores beans and the like in the session context and all has appeared to be
fine thus far. I understand the nature of the various contexts and how they
relate to the process life cycle, etc.
Can someone please shed some light on this and possibly explain the merits
of placing the objects in either context? For example, what are the
pitfalls of using the request context? Is there any material around which
adequately details when or when not to use the specific contexts?
Well, the main merit of placing an object into the request scope is that
it's life ends with the request, so you do not have to remove it
explicitely. Objects placed in session fall into two categories:
- real session objects
- multi-request objects
Real session objects are really tied to one session, like "login id" or
such. Multi-request objects are for instance Struts ActionForms (beans
that correspond to a HTML FORM), which need to be present during several
requests - think wizard style FORMs and FORM validation handling. These
situations require a (form) object to exist longer than just one
request. The alternative would be to store the object in the DB between
requests, which may range from awkward to problematic. What should one
do if the session ends abruptly? Yes, you can have session listeners,
which could track down all intermediary or incomplete objects, but is it
worth the trouble.
OTOH, loading a session with large objects can eat up the memory and
affect not only performance of the system, but it's stability, as well.
The art is finding the "golden median".
Nix.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
