SE-2840 Dr. Mark L. Hornick1 Servlet Threads and Sessions

SE-2840 Dr. Mark L. Hornick2 Servlet execution What are some ramifications of running each doGet() or doPost() on a separate thread??

What can happen here? SE-2840 Dr. Mark L. Hornick3 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 life The 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 SE-2840 Dr. Mark L. Hornick4 These first three are unique to each thread. 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 SE-2840 Dr. Mark L. Hornick5

A related problem: If we use a Servlet’s attributes to store data, only that Servlet can access the data SE-2840 Dr. Mark L. Hornick6 Thread 19 Thread 20 Data store service(request, response) 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. SE-2840 Dr. Mark L. Hornick7 Note: This diagram can be found in your textbook The ServletContext is initialized by Tomcat before any Servlet is initialized.

We know we can use the DD to create ServletContext String parameters…... MyServlet myPackage.MyServlet Some other servlet’s defn goes here... lab1_version SE-2840 Dr. Mark L. Hornick8 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 CS-4220 Dr. Mark L. Hornick9

We need a way to initialize a complex ServletContext attribute before any Servlets are initialized Solution: Use a class that implements the ServletContextListener interface SE-2840 Dr. Mark L. Hornick10 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”); SE-2840 Dr. Mark L. Hornick11

We need to register ServletContextListeners with Tomcat in the DD:... MyServlet test.HelloWorldServlet Some other servlet’s defn goes here... myPackage.MyContextListener </listener... SE-2840 Dr. Mark L. Hornick12

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?? SE-2840 Dr. Mark L. Hornick13

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 SE-2840 Dr. Mark L. Hornick14 ?

SE-2840 Dr. Mark L. Hornick 15 Stateless Pro/Con Good 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

SE-2840 Dr. Mark L. Hornick 16 A web server can ask a browser to set/read/send Cookies as part of the HTTP header Web Browser Web Server HTTP request: “give me a page” HTTP response: “OK, and BTW, store this Cookie”

A Cookie is a small amount of information that can be used to implement state As 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... SE-2840 Dr. Mark L. Hornick 17 Web 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 SE-2840 Dr. Mark L. Hornick 18

SE-2840 Dr. Mark L. Hornick 19 On subsequent visits, the web server can retrieve the Cookies via the HTTP header Web Browser Web Server HTTP request: “give me that page again” HTTP response: “OK, give me that Cookie you stored last time so I can customize the page”

SE-2840 Dr. Mark L. Hornick 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... HelloWorld test.HelloWorldServlet Some other servlet’s defn goes here SE-2840 Dr. Mark L. Hornick21

Tomcat handles session management for Servlets SE-2840 Dr. Mark L. Hornick22 A reference to an HTTPServletRequest is created by the Container and passed to the doGet() and doPost() methods of an HTTPServlet. Session references are retrieved from the Request object. Note: You can look at Cookie objects via request.getCookies(), and set your own Cookie objects via response.addCookie()

This is what we really want SE-2840 Dr. Mark L. Hornick23 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) Each user gets a separate session object which can be used to manage separate data stores. Data store User1 session User2 session