How do servlets work Instantiation sessions shared variables and multithreading

Question

Suppose  I have a webserver which holds numerous servlets  For information passing among those servlets I am setting session and instance variables   Now  if 2 or more users send request to this server then what happens to the session variables  Will they all be common for all the users or they will be different for each user  If they are different  then how was the server able to differentiate between different users   One more similar question  if there are n users accessing a particular servlet  then this servlet gets instantiated only the first time the first user accessed it or does it get instantiated for all the users separately  In other words  what happens to the instance variables

User · Answer

Session in Java servlets is the same as session in other languages such as PHP. It is unique to the user. The server can keep track of it in different ways such as cookies, url rewriting etc. This Java doc article explains it in the context of Java servlets and indicates that exactly how session is maintained is an implementation detail left to the designers of the server. The specification only stipulates that it must be maintained as unique to a user across multiple connections to the server. Check out this article from Oracle for more information about both of your questions.

Edit There is an excellent tutorial here on how to work with session inside of servlets. And here is a chapter from Sun about Java Servlets, what they are and how to use them. Between those two articles, you should be able to answer all of your questions.

User · Answer

Sessions - what Chris Thompson said   Instantiation - a servlet is instantiated when the container receives the first request mapped to the servlet  unless the servlet is configured to load on startup with the  lt load-on-startup gt  element in web xml   The same instance is used to serve subsequent requests

User · Answer

ServletContext  When the servlet container  like Apache Tomcat  starts up  it will deploy and load all its web applications  When a web application is loaded  the servlet container creates the ServletContext once and keeps it in the server s memory  The web app s web xml and all of included web-fragment xml files is parsed  and each  lt servlet gt    lt filter gt  and  lt listener gt  found  or each class annotated with  WebServlet   WebFilter and  WebListener respectively  is instantiated once and kept in the server s memory as well  For each instantiated filter  its init   method is invoked with a new FilterConfig   When a Servlet has a  lt servlet gt  lt load-on-startup gt  or  WebServlet loadOnStartup  value greater than 0  then its init   method is also invoked during startup with a new ServletConfig  Those servlets are initialized in the same order specified by that value  1 is 1st  2 is 2nd  etc   If the same value is specified for more than one servlet  then each of those servlets is loaded in the same order as they appear in the web xml  web-fragment xml  or  WebServlet classloading  In the event the  load-on-startup  value is absent  the init   method will be invoked whenever the HTTP request hits that servlet for the very first time    When the servlet container is finished with all of the above described initialization steps  then the ServletContextListener contextInitialized   will be invoked   When the servlet container shuts down  it unloads all web applications  invokes the destroy   method of all its initialized servlets and filters  and all ServletContext  Servlet  Filter and Listener instances are trashed  Finally the ServletContextListener contextDestroyed   will be invoked   HttpServletRequest and HttpServletResponse  The servlet container is attached to a web server that listens for HTTP requests on a certain port number  port 8080 is usually used during development and port 80 in production   When a client  e g  user with a web browser  or programmatically using URLConnection  sends an HTTP request  the servlet container creates new HttpServletRequest and HttpServletResponse objects and passes them through any defined Filter in the chain and  eventually  the Servlet instance    In the case of filters  the doFilter   method is invoked  When the servlet container s code calls chain doFilter request  response   the request and response continue on to the next filter  or hit the servlet if there are no remaining filters   In the case of servlets  the service   method is invoked  By default  this method determines which one of the doXxx   methods to invoke based off of  request getMethod    If the determined method is absent from the servlet  then an HTTP 405 error is returned in the response    The request object provides access to all of the information about the HTTP request  such as its URL  headers  query string and body  The response object provides the ability to control and send the HTTP response the way you want by  for instance  allowing you to set the headers and the body  usually with generated HTML content from a JSP file   When the HTTP response is committed and finished  both the request and response objects are recycled and made available for reuse   HttpSession  When a client visits the webapp for the first time and or the HttpSession is obtained for the first time via request getSession    the servlet container creates a new HttpSession object  generates a long and unique ID  which you can get by session getId     and stores it in the server s memory  The servlet container also sets a Cookie in the Set-Cookie header of the HTTP response with JSESSIONID as its name and the unique session ID as its value    As per the HTTP cookie specification  a contract any decent web browser and web server must adhere to   the client  the web browser  is required to send this cookie back in subsequent requests in the Cookie header for as long as the cookie is valid  i e  the unique ID must refer to an unexpired session and the domain and path are correct   Using your browser s built-in HTTP traffic monitor  you can verify that the cookie is valid  press F12 in Chrome   Firefox 23    IE9   and check the Net Network tab   The servlet container will check the Cookie header of every incoming HTTP request for the presence of the cookie with the name JSESSIONID and use its value  the session ID  to get the associated HttpSession from server s memory   The HttpSession stays alive until it has been idle  i e  not used in a request  for more than the timeout value specified in  lt session-timeout gt   a setting in web xml  The timeout value defaults to 30 minutes  So  when the client doesn t visit the web app for longer than the time specified  the servlet container trashes the session  Every subsequent request  even with the cookie specified  will not have access to the same session anymore  the servlet container will create a new session   On the client side  the session cookie stays alive for as long as the browser instance is running  So  if the client closes the browser instance  all tabs windows   then the session is trashed on the client s side  In a new browser instance  the cookie associated with the session wouldn t exist  so it would no longer be sent  This causes an entirely new HttpSession to be created  with an entirely new session cookie being used   In a nutshell   The ServletContext lives for as long as the web app lives  It is shared among all requests in all sessions  The HttpSession lives for as long as the client is interacting with the web app with the same browser instance  and the session hasn t timed out at the server side  It is shared among all requests in the same session  The HttpServletRequest and HttpServletResponse live from the time the servlet receives an HTTP request from the client  until the complete response  the web page  has arrived  It is not shared elsewhere  All Servlet  Filter and Listener instances live as long as the web app lives  They are shared among all requests in all sessions  Any attribute that is defined in ServletContext  HttpServletRequest and HttpSession will live as long as the object in question lives  The object itself represents the  scope  in bean management frameworks such as JSF  CDI  Spring  etc  Those frameworks store their scoped beans as an attribute of its closest matching scope    Thread Safety  That said  your major concern is possibly thread safety  You should now know that servlets and filters are shared among all requests  That s the nice thing about Java  it s multithreaded and different threads  read  HTTP requests  can make use of the same instance  It would otherwise be too expensive to recreate  init   and destroy   them for every single request   You should also realize that you should never assign any request or session scoped data as an instance variable of a servlet or filter  It will be shared among all other requests in other sessions  That s not thread-safe  The below example illustrates this   public class ExampleServlet extends HttpServlet        private Object thisIsNOTThreadSafe       protected void doGet HttpServletRequest request  HttpServletResponse response  throws ServletException  IOException           Object thisIsThreadSafe           thisIsNOTThreadSafe   request getParameter  foo       BAD   Shared among all requests          thisIsThreadSafe   request getParameter  foo       OK  this is thread safe             See also    What is the difference between JSF  Servlet and JSP  Best option for Session management in Java Difference between   and    in servlet mapping url pattern doGet and doPost in Servlets Servlet seems to handle multiple concurrent browser requests synchronously Why Servlets are not thread Safe

User · Answer

As is clear from above explanations  by implementing the SingleThreadModel  a servlet can be assured thread-safety by the servlet container  The container implementation can do this in 2 ways   1  Serializing requests  queuing  to a single instance - this is similar to a servlet NOT implementing SingleThreadModel BUT synchronizing the service  doXXX methods  OR  2  Creating a pool of instances - which s a better option and a trade-off between the boot-up initialization effort time of the servlet as against the restrictive parameters  memory  CPU time  of the environment hosting the servlet

User · Answer

No  Servlets are not Thread safe  This is allows accessing more than one threads at a time  if u want to make it Servlet as Thread safe    U can go for  Implement SingleThreadInterface i   which is a blank Interface there is no  methods  or we can go for synchronize methods  we can make whole service method as synchronized by using synchronized  keyword in front of method  Example    public Synchronized class service ServletRequest request ServletResponse response throws ServletException IOException   or we can the put block of the code in the Synchronized block  Example    Synchronized Object      ----Instructions-----      I feel that Synchronized block is better than making the whole method  Synchronized

User · Answer

When the servlet container  like Apache Tomcat  starts up  it will read from the web xml file  only one per application  if anything goes wrong or shows up an error at container side console  otherwise  it will deploy and load all web applications by using web xml  so named it as deployment descriptor   During instantiation phase of the servlet  servlet instance is ready but it cannot serve the client request because it is missing with two pieces of information  1  context information 2  initial configuration information Servlet engine creates servletConfig interface object encapsulating the above missing information into it servlet engine calls init   of the servlet by supplying servletConfig object references as an argument  Once init   is completely executed servlet is ready to serve the client request  Q  In the lifetime of servlet how many times instantiation and initialization happens    A only once  for every client request a new thread is created  only one instance of the servlet serves any number of the client request ie  after serving one client request server does not die  It waits for other client requests ie what CGI  for every client request a new process is created  limitation is overcome with the servlet  internally servlet engine creates the thread   Q How session concept works  A whenever getSession   is called on HttpServletRequest object Step 1  request object is evaluated for incoming session ID  Step 2  if ID not available a brand new HttpSession object is created and its corresponding session ID is generated  ie of HashTable  session ID is stored into httpservlet response object and the reference of HttpSession object is returned to the servlet  doGet doPost   Step 3  if ID available brand new session object is not created session ID is picked up from the request object search is made in the collection of sessions by using session ID as the key  Once the search is successful session ID is stored into HttpServletResponse and the existing session object references are returned to the doGet   or doPost   of UserDefineservlet  Note  1 when control leaves from servlet code to client don t forget that session object is being held by servlet container ie  the servlet engine 2 multithreading is left to servlet developers people for implementing ie   handle the multiple requests of client nothing to bother about multithread code Inshort form  A servlet is created when the application starts  it is deployed on the servlet container  or when it is first accessed  depending on the load-on-startup setting  when the servlet is instantiated  the init   method of the servlet is called then the servlet  its one and only instance  handles all requests  its service   method being called by multiple threads   That s why it is not advisable to have any synchronization in it  and you should avoid instance variables of the servlet when the application is undeployed  the servlet container stops   the destroy   method is called

User · Answer

Sessions     In short  the web server issues a unique identifier to each visitor on his first visit  The visitor must bring back that ID for him to be recognised next time around  This identifier also allows the server to properly segregate objects owned by one session against that of another   Servlet Instantiation  If load-on-startup is false      If load-on-startup is true      Once he s on the service mode and on the groove  the same servlet will work on the requests from all other clients      Why isn t it a good idea to have one instance per client  Think about this  Will you hire one pizza guy for every order that came  Do that and you d be out of business in no time   It comes with a small risk though  Remember  this single guy holds all the order information in his pocket  so if you re not cautious about thread safety on servlets  he may end up giving the wrong order to a certain client

User · Answer

The Servlet Specification JSR-315 clearly defines the web container behavior in the service  and doGet  doPost  doPut etc   methods  2 3 3 1 Multithreading Issues  Page 9       A servlet container may send concurrent requests through the service   method of the servlet  To handle the requests  the Servlet Developer   must make adequate provisions for concurrent processing with multiple   threads in the service method       Although it is not recommended  an alternative for the Developer is to   implement the SingleThreadModel interface which requires the container   to guarantee that there is only one request thread at a time in the   service method  A servlet container may satisfy this requirement by   serializing requests on a servlet  or by maintaining a pool of servlet   instances  If the servlet is part of a Web application that has been   marked as distributable  the container may maintain a pool of servlet   instances in each JVM that the application is distributed across       For servlets not implementing the SingleThreadModel interface  if the   service method  or methods such as doGet or doPost which are   dispatched to the service method of the HttpServlet abstract class    has been defined with the synchronized keyword  the servlet container   cannot use the instance pool approach  but must serialize requests   through it  It is strongly recommended that Developers not synchronize   the service method  or methods dispatched to it  in these   circumstances because of detrimental effects on performance