Ben Engber wrote:
> >> What we do here (using GNUJSP) is have a servlet read all the input, do the
> >> work, and create a bean with all the output variables to substitute. It
> >> puts this bean in the HttpSession and does an
> >> HttpServiceResponse.sendRedirect() to the JSP which uses the bean. This
> >> seems like it would be _terrible_ for performance, not only because it
> >> involves two separate HTTP requests per page but also because it involves
> >> completely unnecessary HttpSession operations.
> >>
> >
> >The sendRedirect() approach works, but does have negative performance
> impacts due
> >to the extra round trip to the client. Howeber, I understand that most
> >implementations of the 0.91 spec supported callPage(), which I thought worked
> >like RequestDispatcher does in 0.92, and handles the redirection on the
> server
> >side.
>
> Okay. Now if I use RequestDispatcher, I'll still need to put the beans in
> the HttpSession, right? This can be an extremely expensive operation in a
> distributed appserver architecture.
>
Depending on the implementation, I suppose it could be expensive, due to the
potential need to serialize the session data. If the engine was set up to return
all requests for the same session back to the same JVM, it would not necessarily
have to be slower, though.
>
> I've noticed some people on the list suggest things like using
> ServletRequest.setAttribute() to pass data to the JSP, but doesn't this go
> against the bean-centric approach JSP advocates? It seems like what you
> really want are beans that last the lifecycle of the current HTTP request
> only. Or am I missing something here?
>
> -Ben
I have not validated this myself, but it appears that when you say
"lifespan=page" in your JSP USEBEAN declaration, it looks for beans that have
been stashed with ServletRequest.setAttribute(), but when you say
"lifespan=session" it looks for beans you have stashed with
HttpSession.putValue(). If this is in fact true, you are still using the
bean-centric approach -- but stashing your bean in one of two different places
depending on the lifespan.
If stashing objects in the session is indeed expensive because of a distributed
appserver architecture, I would hope that stashing them in the current request
and then doing a RequestDispatcher.forward() call would be cheap, since it should
all run within a single JVM -- no serialization issues to worry about.
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
