On Sun, 23 Dec 2001, Ted Husted wrote:
> Date: Sun, 23 Dec 2001 06:57:35 -0500
> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Forced URL rewriting
>
> There was a question on the list a while back regarding URL rewriting
> and clustered servers that I didn't have a good answer for. Basically,
> they want to avoid maintaining the session, apparently as a performance
> tweak. (What I don't know is whether that would actually make a
> difference in real life.)
>
> But, should the tags have an option to supress rewriting (and just
> lookup the path)?
>
> Ideally, you'd think this should fall on the container. The spec does
> require an option to disable cookies, but not so much url rewriting
> (when supported). You could turn this off in Resin, but apparently not
> in Tomcat, and who knows about the others?
>
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg17727.html
>
Sessions are NOT required by the servlet or JSP specifications -- to make
them go away in your application, you should simply don't create a session
(in your servlet), and every JSP page needs to start with:
<%@ page session="false" %>
in order to avoid the default JSP behavior of creating a session.
If you are not in a session, URL rewriting won't change the argument -- it
will be returned unchanged (just as it is when you are in a session but
the container knows that you are using cookies). Providing a
configuration option to make the various Struts tags not call encodeURL()
would be technically feasible, but IMHO it would have a vanishingly small
impact on performance so I cannot see it being worth the bother.
Whether omitting sessions entirely has a performance benefit is impossible
to generalize - it depends very much on how your application server
implements sessions, as well as what you store in them. You also have to
consider the extra cost of the alternatives you employ to deal with the
absence of sessions (such as extra hidden variables in your pages, and/or
storing user state information in a database or EJB). There is no general
rule on what's best.
You should also note that some container features (such as form-based
login) require sessions to be useful. In addition, the following Struts
features cannot operate in the absence of sessions:
* Per-user localization (<bean:message> and friends)
* Transaction tokens to catch resubmits of the same form
because of the back arrow
* Maintaining form beans across multiple pages (without
having all of the properties represented as hidden properties
on every single page).
My experience has been that the scalability issues people run into with
sessions are more related to keeping too many session attributes around
for too long, and not due to the existence of the session itself. In a
distributed environment, there is some amount of overhead (sessions will
need to be "sticky" to a particular server), but the tradeoffs for what
sessions buy you needs to be balanced against this cost.
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
