>> 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.
Yes. Specifically I was considering the case of the Netscape Application
Server, which serializes the objects and broadcasts them throughout the
cluster. Not something you want to do if you don't have to. It is
actually configurable per servlet (applogic), but I wouldn't want to _rely_
on the implementation being smart.
>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.
So it does, at least in GNUJSP. I had thought I was simply supposed to use
the implicit request bean to get those attributes. Is this standard
behaviour (I couldn't tell from the spec)? I think I'll chime in with the
multitudes and say they really ought to document "model 2" better.
In any case, this will almost certainly solve the biggest performance
problems of our current configuration.
Thanks,
Ben
===========================================================================
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".
