Servlet Threads and Sessions SE2840 Dr Mark L

Servlet Threads and Sessions SE-2840 Dr. Mark L. Hornick 1

Servlet execution SE-2840 Dr. Mark L. Hornick What are some ramifications of running each do. Get() or do. Post() on a separate thread? ? 2

What can happen here? User 1 hits Submit on a form page. servi ce(re q uest, respo nse) Thread 19 User 1 Thread 20 Data store Assume the Datastore is managed via a Servlet-owned reference. User 2 hits Submit on the same form page at about the same time. SE-2840 Dr. Mark L. Hornick 3

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): l l Http. Servlet. Request object These first three are unique to each thread. Http. Servlet. Response object Local Servlet method variables Servlet class/instance constants Reading is thread-safe These are NOT thread-safe: l l l Servlet class attribute variables Servlet. Config object These are objects are shared among threads. Servlet. Context object SE-2840 Dr. Mark L. Hornick 4

Are any of the following good approaches to avoid threading problems? Synchronize a Servlet’s service methods 1. l Let only a single thread at a time execute do. Get(), do. Post(), etc Synchronize a block of code within a method 2. l Let only a single thread at a time execute critical sections. Synchronize on the Servlet. Config object 3. l Let only a single thread at a time access any Servlet-specific data Synchronize on the Servlet. Context object 4. l Let only a single thread at a time access any Context-specific (that is, web application-specific) data SE-2840 Dr. Mark L. Hornick 5

A related problem: If we use a Servlet’s attributes to store data, only that Servlet can access the data servi ce(re q uest, respo nse) 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? ? ? SE-2840 Dr. Mark L. Hornick 6

Using Servlet. Context to store data would make it accessible to all Servlets in the web app. The Servlet. Context is initialized by Tomcat before any Servlet is initialized. Note: This diagram can be found in your textbook SE-2840 Dr. Mark L. Hornick 7

We know we can use the DD to create Servlet. Context String parameters… <? xml version="1. 0" encoding="UTF-8"? >. . . <servlet> <servlet-name>My. Servlet</servlet-name> <servlet-class>my. Package. My. Servlet</servlet-class>. . . </servlet> <servlet>. . . Some other servlet’s defn goes here </servlet>. . . <!-- Here is a context parameter that all Servlets in this web app can see --> <context-param> <param-name>lab 1_version</param-name> <param-value>2. 1</param-value> </context-param>. . . </web-app> But what if we want to initialize something more complex? SE-2840 Dr. Mark L. Hornick 8

Servlet. Context: Parameters vs. Attributes l l l 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 9

We need a way to initialize a complex Servlet. Context attribute before any Servlets are initialized Solution: Use a class that implements the Servlet. Context. Listener interface This is one of 8 different Listeners The event class SE-2840 Dr. Mark L. Hornick 10

The context. Initialized() event handler is called by Tomcat at startup In the context. Initialized() method, we can create a Servlet. Context attribute that is a complex datatype: public void context. Initialized(Servlet. Context. Event e) { Servlet. Context context = e. get. Servlet. Context(); context. set. Attribute(“foo”, new My. Complex. Type() ); } // later, any Servlet will be able to access My. Complex. Type via a call to get. Servlet. Context(). get. Attribute(“foo”); SE-2840 Dr. Mark L. Hornick 11

We need to register Servlet. Context. Listeners with Tomcat in the DD: <? xml version="1. 0" encoding="UTF-8"? >. . . <servlet> <servlet-name>My. Servlet</servlet-name> <servlet-class>test. Hello. World. Servlet</servlet-class>. . . </servlet> <servlet>. . . Some other servlet’s defn goes here </servlet>. . . <!– Here’s how a Servlet. Context. Listener is registered --> <listener-class>my. Package. My. Context. Listener</listener-class> </listener. . . </web-app> SE-2840 Dr. Mark L. Hornick 12

Finally…thread-safe data accessed as a Servlet. Context attribute l All users sharing the same object maintained by the Servlet. Context… l Is this really what we want? ? SE-2840 Dr. Mark L. Hornick 13

By default, Servlets have no memory of who makes a request l The HTTP protocol is stateless, meaning it does not keep track of ongoing request/response messages. l Each HTTP request/response is independent of any other request/response SE-2840 Dr. Mark L. Hornick ? 14

Stateless Pro/Con Good for browsing and hyperlinking pages in any order without regard to past history l No HTTP overhead in maintaining state Bad for applications that require complex user interaction between web pages l The web application may want/need to know l l what page you’ve visited previous to the current page What you’ve done on previous visits SE-2840 Dr. Mark L. Hornick 15

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 HTTP response: “OK, and BTW, store this Cookie” SE-2840 Dr. Mark L. Hornick Web Server 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 l l l Previous date of web site access Login status. . . Web Browser Cookie information SE-2840 Dr. Mark L. Hornick 17

A Cookie has various properties l l l l 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

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” SE-2840 Dr. Mark L. Hornick 19

Session Protocol l User's browser is given a session ID by the server l Tomcat does this automatically l l ID is included in subsequent HTTP exchanges with the server l l l Cookie expiration is usually very short; sometimes longer “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 l Persist somewhere on the server filesystem or server db SE-2840 Dr. Mark L. Hornick 20

Application Session lifetime can be adjusted <? xml version="1. 0" encoding="UTF-8"? >. . . <servlet> <servlet-name>Hello. World</servlet-name> <servlet-class>test. Hello. World. Servlet</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> SE-2840 Dr. Mark L. Hornick 21

Tomcat handles session management for Servlets A reference to an HTTPServlet. Request is created by the Container and passed to the do. Get() and do. Post() methods of an HTTPServlet. Note: You can look at Cookie objects via request. get. Cookies(), and set your own Cookie objects via response. add. Cookie() SE-2840 Dr. Mark L. Hornick Session references are retrieved from the Request object. 22

This is what we really want User 1 hits Submit on a form page. servi ce(re q uest, respo nse) Data store Thread 19 respo nse) User 1 session Thread 20 User 2 session User 2 hits Submit on the same form page at about the same time. SE-2840 Dr. Mark L. Hornick Data store Each user gets a separate session object which can be used to manage separate data stores. 23