servlet threads and sessions

CS-4220 Dr. Mark L. Hornick 1

Servlet Threads and Sessions


Servlet execution

What are some ramifications of running each doGet() or doPost()on a separate thread??

What can happen here?


User 1

User 1 hits Submit on a form page.

Thread 19

User 2

Thread 20 Data

store

User 2 hits Submit on the same form page at about the same time.

service(request, response)


Assume the Datastore is managed via a Servlet-owned reference.

Multithreading is a fact of a Servlet’s lifeThe only code objects that are thread-safe are

the ones that are stack-based (or readonly): HttpServletRequest object HttpServletResponse object Local Servlet method variables Servlet class/instance constants

These are NOT thread-safe: Servlet class attribute variables ServletConfig object ServletContext object


These first three are unique to eachthread.

Reading is thread-safe

These are objects are shared among threads.

Are any of the following good approaches to avoid threading problems?1. Synchronize a Servlet’s service methods

Let only a single thread at a time execute doGet(), doPost(), etc

2. Synchronize a block of code within a method Let only a single thread at a time execute critical sections.

3. Synchronize on the ServletConfig object Let only a single thread at a time access any Servlet-specific

data

4. Synchronize on the ServletContext object Let only a single thread at a time access any Context-specific

(that is, web application-specific) data


Another problem: If we use a Servlet’s attributes to store data, only that Servlet can access the data


Thread 19

Thread 20 Data

store



What if we wanted a different Servlet to generate the response, in order to separate class responsibilities and improve cohesion?

And what happens if our Servlet is used in another web app on the same server???

Using ServletContext to store data would make it accessible to all Servlets in the web app.


Note: This diagram canbe found in your textbook

The ServletContext is initializedby Tomcat before any Servlet is initialized.

We know we can use the DD to create ServletContext String parameters…

<?xml version="1.0" encoding="UTF-8"?>...<servlet>

<servlet-name>MyServlet</servlet-name><servlet-class>myPackage.MyServlet</servlet-class>

...</servlet><servlet>... Some other servlet’s defn goes here</servlet>... <context-param>

<param-name>lab1_version</param-name><param-value>2.1</param-value>

</context-param>

...</web-app>


But what if we want to initialize something more complex?

ServletContext: Parameters vs. Attributes Parameters are init’d in the DD Parameters are name/value pairs,

where the value is a String Parameters are readonly

Attributes can be created/modified by code

Attributes are name/value pairs, where the value is an Object

Attributes are read/write


We need a way to initialize a complex ServletContext attribute before any Servlets are initialized

Solution: Use a class that implements the ServletContextListener interface


This is one of 8 different Listeners

The event class

The contextInitialized() event handler is called by Tomcat at startup

In the contextInitialized() method, we can create a ServletContext attribute that is a complex datatype:

public void contextInitialized(ServletContextEvent e) {ServletContext context = e.getServletContext();context.setAttribute(“foo”, new

MyComplexType() );}

// later, any Servlet will be able to access MyComplexType via a call to getServletContext().getAttribute(“foo”);


We need to register ServletContextListeners with Tomcat in the DD:


<servlet-name>MyServlet</servlet-name><servlet-class>test.HelloWorldServlet</servlet-class>

...</servlet><servlet>... Some other servlet’s defn goes here</servlet>...<!– Here’s how a ServletContextListener is registered --> <listener>

<listener-class>myPackage.MyContextListener</listener-class></listener...

</web-app>


Finally…thread-safe data accessed as a ServletContext attribute

All users sharing the same object maintained by the ServletContext… Is this really what we want??


By default, Servlets have no memory of who makes a request The HTTP protocol is stateless,

meaning it does not keep track of ongoing request/response messages.

Each HTTP request/response is independent of any other request/response


?

CS-422Dr. Mark L. Hornick

15

Stateless Pro/ConGood for browsing and hyperlinking

pages in any order without regard to past history No HTTP overhead in maintaining state

Bad for applications that require complex user interaction between web pages The web application may want/need to

know what page you’ve visited previous to the current

page What you’ve done on previous visits

A Cookie is a small amount of information that can be used to implement stateAs a web site developer, you can store

information you gather from a user on the file system of the user’s PC as a Cookie Previous date of web site access Login status . . .


16Web Browser Cookie information

A Cookie has various properties

name – the cookie name value – the value of the cookie expires – the date the cookie expires path – path in domain in which cookie is visible domain – domain the cookie is visible to secure – cookie is only available over secure

connections httponly – cookie is only available via HTTP


17


18

A web server can ask a browser to set/read/send Cookies as part of the HTTP header

Web BrowserWeb Server

HTTP request: “give me a page”

HTTP response: “OK, and BTW,store this Cookie”


19

On subsequent visits, the web server can retrieve the Cookies via the HTTP header

Web BrowserWeb Server

HTTP request: “give me that page again”

HTTP response: “OK, give me thatCookie you stored last time so I cancustomize the page”


20

Session Protocol User's browser is given a session ID by the server

Tomcat does this automatically Cookie expiration is usually very short; sometimes longer

ID is included in subsequent HTTP exchanges with the server “subsequent” can be even weeks later (usually not)

Server uses received session ID to locate/ retrieve corresponding session data/variables

Session variables kept on server for efficiency and security Persist somewhere on the server filesystem or server db

Application Session lifetime can be adjusted


<servlet-name>HelloWorld</servlet-name><servlet-class>test.HelloWorldServlet</servlet-class>

...</servlet><servlet>... Some other servlet’s defn goes here</servlet>...<!– Session life in minutes; 0 means end w/ browser session --> <session-config>

<session_timeout>30</session_timeout> </session-config>...

</web-app>


Tomcat handles session management for Servlets


A reference to an HTTPServletRequest is created by the Containerand passed to the doGet() and doPost() methods of an HTTPServlet.

Session references are retrieved from the Request object.

This is what we really want


User 1

User 1 hits Submit on a form page.

Thread 19

User 2

Thread 20

Datastore

User 2 hits Submit on the same form page at about the same time.



Each user gets a separate session object which can be used to manage separate data stores.

Datastore

User1 session

User2 session

servlet threads and sessions

Documents

single thread

separate thread

different servlet

servletcontext objectlet

servlets attributes

servlets lifethe

servlets defn

servletowned reference