Datasheet

Patrick c01.tex V3 - 09/18/2009 12:15pm Page 11

Chapter 1: Building Web Applications in WebLogic

Best Practice

Disable session tracking in JSP pages that do not require this feature to avoid

unnecessary session persistence.

Like servlets, JSP pages are normally multithreaded and may process multiple requests simultane-

ously. The same thread-safety restrictions that apply to servlets also apply to JSP pages unless the

JSP is conﬁgured to be single threaded. In a JSP page a special

page

directive is used to conﬁgure

this attribute:

<%@ page isThreadSafe="false" %>

If the

isThreadSafe

attribute is set to

false

, the resulting servlet will implement the

SingleThreadModel

interface. This technique, like the related servlet technique, is deprecated in

the Servlet 2.4 speciﬁcation and should be avoided.

Best Practice

Avoid declaring JSP pages to be single threaded. Code that is not thread-safe

should be encapsulated in some other Java class and controlled using synchro-

nization blocks.

JSP Response Is Buffered

As we said, servlets and JSP pages are request/response mechanisms: An HTTP request is made

by the browser, and an HTML response is generated by the servlet or JSP page. In both cases, this

response is normally buffered, or held in memory on the server temporarily, and sent back to the

calling browser at the end of the processing.

By default, output created in the generated servlet code is buffered, along with HTTP head-

ers, cookies, and status codes set by the page. Buffering provides you with these important

beneﬁts:

❑ Buffered content may be discarded completely and replaced with new content. The

jsp:forward

element relies on this capability to discard the current response and forward

the HTTP request to a new page for processing. Note that the

errorPage

directive uses

jsp:forward

to send the processing to the error page if an error is caught in the JSP page,

so buffering is also required for proper error page handling.

❑ Buffering allows the page to add or change HTTP headers, cookies, and status codes after

the page has begun placing HTML content in the response. Without buffering, it would

be impossible to add a cookie in the body of the JSP page or change the response to be a

redirect (302) to a different page once output is written because the headers and cookies

have already been sent.