Servlet Programming Tasks 9-21
Example 9–5 Overriding doTimeOut in AbstractAsyncServlet.java
public void doTimeout RequestResponseKey rrk throws ServletException, IOException
{ HttpServletRequest req = rrk.getRequest;
HttpServletResponse res = rrk.getResponse;
res.setContentTypetexthtml; PrintWriter out = res.getWriter;
out.printlnTimeout; }
9.16.2 Future Response Servlet
Although Oracle recommends using the Abstract Asynchronous Servlet, you can also use the Future Response Servlet to handle servlet responses with a different thread
than the one that handles the incoming request. You enable this servlet by extending weblogic.servlet.FutureResponseServlet.java, which gives you full
control over how the response is handled and allows more control over thread handling. However, using this class to avoid hung threads requires you to provide
most of the code.
The exact implementation depends on your needs, but you must override the service method of this class at a minimum. The following example shows how
you can override the service method.
Example 9–6 Overriding the service method of FutureResponseServlet.java
public void serviceHttpServletRequest req, FutureServletResponse rsp throws IOException, ServletException {
ifreq.getParameterimmediate = null{ PrintWriter out = rsp.getWriter;
out.printlnImmediate response; rsp.send;
} else { Timer myTimer = new Timer;
MyTimerTask mt = new MyTimerTaskrsp, myTimer; myTimer.schedulemt, 100;
} }
private static class MyTimerTask extends TimerTask{ private FutureServletResponse rsp;
Timer timer; MyTimerTaskFutureServletResponse rsp, Timer timer{
this.rsp = rsp; this.timer = timer;
} public void run{
try{ PrintWriter out = rsp.getWriter;
out.printlnDelayed Response;
Note: The servlet instance that processed the doRequest method
used to handle the original incoming request method will not necessarily be the one to process the doTimeOut method.
9-22 Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server
rsp.send; timer.cancel;
} catchIOException e{
e.printStackTrace; }
} }
10
Using Sessions and Session Persistence 10-1
10
Using Sessions and Session Persistence
The following sections describe how to set up and use sessions and session persistence:
■
Section 10.1, Overview of HTTP Sessions
■
Section 10.2, Setting Up Session Management
■
Section 10.3, Configuring Session Persistence
■
Section 10.4, Using a Database for Persistent Storage JDBC Persistence
■
Section 10.5, Using URL Rewriting Instead of Cookies
■
Section 10.6, Session Tracking from a Servlet
10.1 Overview of HTTP Sessions
Session tracking enables you to track a users progress over multiple servlets or HTML pages, which, by nature, are stateless. A session is defined as a series of related browser
requests that come from the same client during a certain time period. Session tracking ties together a series of browser requests—think of these requests as pages—that may
have some meaning as a whole, such as a shopping cart application.
10.2 Setting Up Session Management
WebLogic Server is set up to handle session tracking by default. You need not set any of these properties to use session tracking. However, configuring how WebLogic
Server manages sessions is a key part of tuning your application for best performance. When you set up session management, you determine factors such as:
■
How many users you expect to hit the servlet
■
How long each session lasts
■
How much data you expect to store for each user
■
Heap size allocated to the WebLogic Server instance You can also store data permanently from an HTTP session. See
Section 10.3, Configuring Session Persistence
.
10.2.1 HTTP Session Properties
You configure WebLogic Server session tracking by defining properties in the WebLogic-specific deployment descriptor, weblogic.xml. For a complete list of
session attributes, see Section B.10, session-descriptor
.
