Servlet Threads and Sessions

1. Servlet Threads and Sessions CS-4220 Dr. Mark L. Hornick

2. Servlet execution What are some ramifications of running each doGet() or doPost()on a separate thread?? CS-4220 Dr. Mark L. Hornick

3. What can happen here? User 1 hits Submit on a form page. service(request, response) service(request, response) Thread 19 User 1 Datastore Thread 20 Assume the Datastore is managed via a Servlet-owned reference. User 2 hits Submit on the same form page at about the same time. User 2 CS-4220 Dr. Mark L. Hornick

4. 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 These first three are unique to eachthread. Reading is thread-safe These are objects are shared among threads. CS-4220 Dr. Mark L. Hornick

5. Are any of the following good approaches to avoid threading problems? • Synchronize a Servlet’sservice methods • Let only a single thread at a time execute doGet(), doPost(), etc • Synchronize a block of code within a method • Let only a single thread at a time execute critical sections. • Synchronize on the ServletConfig object • Let only a single thread at a time access any Servlet-specific data • Synchronize on the ServletContext object • Let only a single thread at a time access any Context-specific (that is, web application-specific) data CS-4220 Dr. Mark L. Hornick

6. Another problem: If we use a Servlet’s attributes to store data, only that Servlet can access the data service(request, response) service(request, response) Thread 19 Datastore Thread 20 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??? CS-4220 Dr. Mark L. Hornick

7. Using ServletContext to store data would make it accessible to all Servlets in the web app. The ServletContext is initializedby Tomcat before any Servlet is initialized. Note: This diagram canbe found in your textbook CS-4220 Dr. Mark L. Hornick

8. We know we can use the DD to create ServletContextString 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’sdefn goes here </servlet> ... <!-- Here is a context parameter that all Servlets in this web app can see --> <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? CS-4220 Dr. Mark L. Hornick

9. 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. Hornick

10. We need a way to initialize a complex ServletContextattribute before any Servlets are initialized Solution: Use a class that implements the ServletContextListener interface This is one of 8 different Listeners The event class CS-4220 Dr. Mark L. Hornick

11. 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”); CS-4220 Dr. Mark L. Hornick

12. We need to register ServletContextListeners with Tomcat in the DD: <?xml version="1.0" encoding="UTF-8"?> ... <servlet> <servlet-name>MyServlet</servlet-name> <servlet-class>test.HelloWorldServlet</servlet-class> ... </servlet> <servlet> ... Some other servlet’sdefn goes here </servlet> ... <!– Here’s how a ServletContextListener is registered --> <listener> <listener-class>myPackage.MyContextListener</listener-class> </listener ... </web-app> CS-4220 Dr. Mark L. Hornick

13. 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?? CS-4220 Dr. Mark L. Hornick

14. 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-4220 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 CS-422Dr. Mark L. Hornick

16. 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 • . . . Cookie information Web Browser CS-422Dr. Mark L. Hornick

17. 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 CS-422Dr. Mark L. Hornick

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

19. On subsequent visits, the web server can retrieve the Cookies via the HTTP header HTTP request: “give me that page again” Web Browser Web Server HTTP response: “OK, give me that Cookie you stored last time so I can customize the page” CS-422Dr. 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 CS-422Dr. Mark L. Hornick

21. Application Session lifetime can be adjusted <?xml version="1.0" encoding="UTF-8"?> ... <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>test.HelloWorldServlet</servlet-class> ... </servlet> <servlet> ... Some other servlet’sdefn goes here </servlet> ... <!– Session life in minutes; 0 means end w/ browser session --> <session-config> <session_timeout>30</session_timeout> </session-config> ... </web-app> CS-4220 Dr. Mark L. Hornick

22. 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. CS-4220 Dr. Mark L. Hornick

23. This is what we really want User 1 hits Submit on a form page. service(request, response) Datastore service(request, response) Thread 19 User 1 User1 session Thread 20 Datastore User2 session Each user gets a separate session object which can be used to manage separate data stores. User 2 hits Submit on the same form page at about the same time. User 2 CS-4220 Dr. Mark L. Hornick