How do servlets work? Instantiation, session variables and multithreading

Suppose, I have a webserver which holds numerous  Servlets . For information passing among those Servlets  I am getting the `Servlets` context and setting session 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  Servlets , then this Servlets gets instantiated only the first time the first user accessed it or does it get instantiated for all the users separately?



##ServletContext

When the servletcontainer like Apache Tomcat starts up, it will deploy and load all webapplications. When a webapplication get loaded, the servletcontainer will create the    ServletContext  once and keep in server's memory. The webapp's `web.xml` will be parsed and every servlet  filter  and listener  found in  web.xml, or annotated with respectively  @WebServlet, `@WebFilter` and @WebListener, will be created once and kept in server's memory as well. For all filters, the `init()` method will also be invoked immediately. When the servletcontainer shuts down, it will unload all webapplications, invoke the `destroy()` of all initialized servlets and filters, and finally the `ServletContext` and all `Servlet`, `Filter` and `Listener` instances will be trashed.

When the `Servlet` in question has a  servlet  load-on-startup or  @WebServlet(loadOnStartup) value greater than `0`, then its `init()` method will also immediately be invoked during startup. Those servlets are initialized in the same order as "load-on-startup" value represents, or if they are the same, then the order in the `web.xml` or `@WebServlet` classloading. Or, if the "load-on-startup" value is absent, then the `init()` method will only be invoked on very first HTTP request hitting the servlet in question. 

##HttpServletRequest and HttpServletResponse

The servletcontainer is attached to a webserver which listens on HTTP requests on a certain port number, which is usually 8080 in development and 80 in production. When a client (user with a webbrowser) sends a HTTP request, the servletcontainer will create new  HttpServletRequest  and  HttpServletResponse objects and pass it through the methods of the already-created `Filter` and Servlet  instances whose `url-pattern` matches the request URL, all in the same thread. 

The request object provides access to all information of the HTTP request, such as the request headers and the request body. The response object provides facility to control and send the HTTP response the way you want, such as setting headers and the body (usually with HTML content from a JSP file). When the HTTP response is committed and finished, then both the request and response objects will be trashed.

##HttpSession

When a client visits the webapp for the first time and/or the  HttpSession  is to be obtained for the first time by   request.getSession(), then the servletcontainer will create it, generate a long and unique ID (which you can get by `session.getId()`) and store it in server's memory. The servletcontainer will also set a [`Cookie`][6] in the `Set-Cookie` header of the HTTP response with `JSESSIONID` as cookie name and the unique session ID as cookie value. 

As per the HTTP cookie specification  (a contract a decent webbrowser and webserver has to adhere), the client (the webbrowser) is required to send this cookie back in the subsequent requests in the `Cookie` header as long as the cookie is valid. Using browser builtin HTTP traffic monitor you can check them (press F12 in Chrome / Firefox23+ / IE9+ and check *Net/Network* tab). The servletcontainer will determine 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` lives until it has not been used for more than the session-timeout  time, a setting you can specify in web.xml, which defaults to 30 minutes. So when the client doesn't visit the webapp anymore for over 30 minutes, then the servletcontainer will trash the session. Every subsequent request, even though with the cookie specified, will not have access to the same session anymore. The servletcontainer will create a new one. 

On the other hand, the session cookie on the client side has a default lifetime which is as long as the browser instance is running. So when the client closes the browser instance (all tabs/windows), then the session will be trashed at the client side. In a new browser instance the cookie associated with the session won't be sent anymore. A new `request.getSession()` would return a brand new `HttpSession` and set a cookie with a brand new session ID.

##In a nutshell

- The `ServletContext` lives as long as the webapp lives. It's been shared among  all  requests in all sessions.
- The `HttpSession` lives as long as the client is interacting with the webapp with the same browser instance and the session hasn't timed out at the server side yet. It's been shared among   all requests in the same session.
- The `HttpServletRequest` and `HttpServletResponse` lives as long as the client has sent it until the complete response (the webpage) is arrived. It is  not being shared elsewhere.
- Any `Servlet`, `Filter` and `Listener` lives as long as the webapp lives. They are being shared among   all   requests in  all  sessions.
- Any `attribute` which you set in `ServletContext`, `HttpServletRequest` and `HttpSession` will live as long as the object in question lives.


##Threadsafety

That said, your major concern is possibly *threadsafety*. You should now have learnt that Servlets and filters are shared among all requests. That's the nice thing of Java, it's multithreaded and different threads (read: HTTP requests) can make use of the same instance. It would otherwise have been too expensive to recreate it on every request.

But 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  threadunsafe ! The below example illustrates that:

    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:

Servlets and Multithreading
Difference between JSP and Servlet
Session management in Java

How to use Comparator and Comparable in Java? With example

1) Comparator in Java is defined in java.util package while Comparable interface in Java is defined in java.lang package, which very much says that Comparator should be used as an utility to sort objects which Comparable should be provided by default.

2) Comparator interface in Java has method public int compare (Object o1, Object o2) which returns a negative integer, zero, or a positive integer as the first argument is less than, equal to, or greater than the second. While Comparable interface has method public int compareTo(Object o) which returns a negative integer, zero, or a positive integer as this object is less than, equal to, or greater than the specified object.

3) If you see then logical difference between these two is Comparator in Java compare two objects provided to him, while Comparable interface compares "this" reference with the object specified. I have shared lot of tips on how to override compareTo() method and avoid some common mistakes programmer makes while implementing Comparable interface.

4) Comparable in Java is used to implement natural ordering of object. In Java API String, Date and wrapper classes implements Comparable interface.Its always good practice to override compareTo() for value objects.

5) If any class implement Comparable interface in Java then collection of that object either List or Array can be sorted automatically by using  Collections.sort() or Arrays.sort() method and object will be sorted based on there natural order defined by CompareTo method.

6)Objects which implement Comparable in Java  can be used as keys in a SortedMap like TreeMap or elements in a SortedSet  for example TreeSet, without specifying any Comparator.

These were combination of some theoretical and practical differences between Comparator and Comparator interface in Java. It does help you to decide when to use Comparator vs Comparable but things will be more clear when we some best practices around using both of these interfaces. Now let’s see an example of Comparator in Java:

Example of using Comparator and Comparable in Java

So in Summary if you want to sort objects based on natural order then use Comparable in Java and if you want to sort on some other attribute of object then use Comparator in Java. Now to understand these concepts lets see an example or real life coding:

1) There is class called Person, sort the Person based on person_id, which is primary key in database

2) Sort the Person based on there name.

For a Person class, sorting based on person_id can be treated as natural order sorting and sorting based on name field can be implemented using Comparator interface. To sort based on person_id we need to implement compareTo() method.

public class Person implements Comparable {
    private int person_id;
    private String name;
 
    /**
     * Compare current person with specified person
     * return zero if person_id for both person is same
     * return negative if current person_id is less than specified one
     * return positive if specified person_id is greater than specified one
     */
    @Override 
    public int compareTo(Object o) {
        Person p = (Person) o; 
        return this.person_id - o.person_id ;
    }
    ….
}

Generally you should not use difference of integers to decide output of compareTo method as result of integer subtraction can overflow but if you are sure that both operands are positive then its one of the quickest way to compare two objects. See my post things to remember while overriding compareTo in Java for more tips on compareTo.

And for sorting based on person name we can implement compare(Object o1, Object o2) method of Java Comparator class.

/**
 * Comparator implementation which sorts Person objects on person_id field
 */
public class SortByPerson_ID implements Comparator{

    public int compare(Object o1, Object o2) {
        Person p1 = (Person) o;
        Person p2 = (Person) o; 
        return p1.getPersonId() - p2.getPersonId();
    }
}

Similar guidelines applies while implementing compare() method as well and instead of using subtraction operator, its better to use logical operator to compare whether two integers are equal to, less than or greater than. You can write several types of Java Comparator based upon your need for example  reverseComparator , ANDComparator , ORComparator etc which will return negative or positive number based upon logical results. String in Java even provides an special comparator called CASE_INSENSITIVE_ORDER, to perform case insensitive comparison of String objects.

How to Compare String in Java

String is immutable in Java and one of the most used value class. For comparing String in Java we should not be worrying because String implements Comparable interface and provides a lexicographic implementation for CompareTo method which compare two strings based on contents of characters or you can say in lexical order. You just need to call String.compareTo(AnotherString) and Java will determine whether specified String is greater than , equal to or less than current object. See my post 4 example to compare String in Java for alternatives ways of comparing String.

How to Compare Dates in Java

Dates are represented by java.util.Date class in Java and like String,  Date also implements Comparable in Java so they will be automatically sorted based on there natural ordering if they got stored in any sorted collection like TreeSet or TreeMap. If you explicitly wants to compare two dates in Java you can call Date.compareTo(AnotherDate) method in Java and it will tell whether specified date is greater than , equal to or less than current String. See my post 3 ways to compare Dates in Java for more alternatives of comparing two dates.

When to use Comparator and Comparable in Java

At last let’s see some best practices and recommendation on when to use Comparator or Comparable in Java:

1) If there is a natural or default way of sorting Object already exist during development of Class than use Comparable. This is intuitive and you given the class name people should be able to guess it correctly like Strings are sorted chronically, Employee can be sorted by there Id etc. On the other hand if an Object can be sorted on multiple ways and client is specifying on which parameter sorting should take place than useComparator interface. for example Employee can again be sorted on name, salary or department and clients needs an API to do that. Comparator implementation can sort out this problem.

2) Some time you write code to sort object of a class for which you are not the original author, or you don't have access to code. In these cases you can not implement Comparable and Comparator is only way to sort those objects.

3) Beware with the fact that How those object will behave if stored in SorteSet or SortedMap like TreeSet and TreeMap. If an object doesn't implement Comparable than while putting them into SortedMap, always provided corresponding Comparator which can provide sorting logic.

4) Order of comparison is very important while implementing Comparable or Comparator interface. for example if you are sorting object based upon name than you can compare first name or last name on any order, so decide it judiciously. I have shared more detailed tips on compareTo on my post how to implement CompareTo in Java.

5) Comparator has a distinct advantage of being self descriptive  for example if you are writing Comparator to compare two Employees based upon there salary than name that comparator as SalaryComparator, on the other hand compareTo()

Difference between String literal and New String object in Java

String is a special class in Java API and has so many special behaviours which is not obvious

to many programmers. In order to master Java, first step is to master String class, and one 
way to explore is checking what kind of String related questions are asked on Java interviews.
 Apart from usual questions like why String is final, or  equals vs == operator, one of the most
frequently asked question is what is difference between String literal and String object in
 Java.For example, what is the difference between String object created in following two
 expression :

String strObject = new String("Java");

and

String strLiteral = "Java";

Both expression gives you String object, but there is subtle difference between them. When
you create String object using new() operator, it always create a new object in heap
 memory. On theother hand, if you create object using String literal syntax e.g. "Java",
 it may return an existing object from String pool (a cache of String object in Perm gen
 space, which is now moved to heap space in recent Java release), if it's already exists. 
Otherwise it will create a new string object and put in string pool for future re-use. In 
rest of this article, why it is one of the most important thing
 you should remember about String in Java.

What is String literal and String Pool

Since String is one of the most used type in any application, Java designer took a step further
to optimize uses of this class. They know that Strings will not going to be cheap, and that's
 why they come up with an idea to cache all String instances created inside double quotes
 e.g. "Java".These double quoted literal is known as String literal and the cache which 
stored these String instances are known as as String pool. In earlier version of Java, I think 
up-to Java 1.6 String pool is located in permgen area of heap, but in Java 1.7 updates its 
moved to main heap area. Earlier since it was in PermGen space, it was always a risk to 
create too many String object, because its a very limited space, default size 64 MB and used
 to store classmetadata e.g. .class files. Creating too many String literals can cause
 java.lang.OutOfMemory: permgen space. Now because String pool is moved to a much 
larger memory space, it's much more safe. By the way, don't misuse memory
here, always try to minimize temporary String object e.g. "a", "b" and then "ab".
Always use StringBuilder to deal with temporary String object.

Difference between String literal and String object

At high level both are String object, but main difference comes from the point that new()
operator always creates a new String object. Also when you create String using literal they 
are interned. This will be much more clear when you compare two String objects created 
using String literal and new operator, as shown in below example :

String a = "Java";
String b = "Java";
System.out.println(a == b);  // True

Here two different objects are created and they have different references:

String c = new String("Java");
String d = new String("Java");
System.out.println(c == d);  // False

Similarly when you compare a String literal with an String object created using new()
 operator using ==operator, it will return false, as shown below :

String e = "JDK";
String f =  new String("JDK");
System.out.println(e == f);  // False

In general you should use the string literal notation when possible. It is easier to read and
it gives  the compiler a chance to optimize your code. By the way any answer to this 
question is incomplete until you explain what is String interning, so let's see that in
 next section.

String interning using inter() method

Java by default doesn't put all String object into String pool, instead they gives you
flexibility to explicitly store any arbitrary object in String pool. You can put any object
to String pool by calling intern()method of java.lang.String class. Though,
 when you create using String  literal notation of Java, it automatically call intern()
 method to put that object into String pool, provided it was not present in the pool 
already. This is another difference between string literal and  new string, because in 
case of new, interning doesn't happen automatically, until you call intern() method
 on that object. Also don't forget to use StringBuffer and StringBuilder for
string concatenation, they will reduce number


That's all about this question, what is difference between String literal and String object 
in Java. Always remember that literal Strings are returned from string pool and Java put
them in pool if not stored already. This difference is most obvious, when you compare two 
String objects using equality operator (==). That's why it's suggested as always compare 
two String object using equals() method and never compare them using == operator,
 because you never know which one is coming from pool and which one is created using
 new() operator. If you know the difference between string object and string literal, you
 can also solve questions from Java written test, which also test this concept. It's something, 
every Java programmer should know.  of temporary
String object in heap space.

Serialization in Java

JAVA: Serialization in Java: If a class is serializable, it means that object of that class can be converted into a sequence of bits so that it can be written to some s...

Difference between MyClass.class and this

JAVA: Difference between MyClass.class and this: this :  It refers to  the current instance of the class where you are working on. MyClass.class:  It refers to the Class instance tha...

MySQL and Java JDBC ,Connection to database with Java

By Sitansu S Swain

package com.demo.mysqlaccess;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

public class MySqlAccess {
private Connection connection = null;
private Statement statement = null;
private PreparedStatement preparedStatement = null;
private ResultSet resultSet = null;

public void readDataBase() throws Exception {
try {
// This will load the MySql Driver, each DB has its own driver
Class.forName("com.mysql.jdbc.Driver");

// Setup connection with the DB
connection = DriverManager.getConnection("jdbc:mysql://localhost/springdemoproject?" + "user=root&password=");

// Statement allow to issue the Sql queries to the Database
statement = connection.createStatement();

// ResultSet gets the result of the Sql Query.
resultSet = statement.executeQuery("SELECT * FROM login");
writeResultSet(resultSet);

// preparestatement can use variables and more efficient
preparedStatement = connection.prepareStatement("insert into login values(default,?,?,?,?)");

// Here parameter start with index 1
preparedStatement.setString(1, "Sitansu");
preparedStatement.setString(2, "sitansudev");
preparedStatement.setInt(3, 97189);
preparedStatement.setString(4, "orissa");
preparedStatement.executeUpdate();
preparedStatement = connection.prepareStatement("select name,password from login");
resultSet = preparedStatement.executeQuery();
writeResultSet(resultSet);

// Remove again the insert login
preparedStatement = connection.prepareStatement("delete from login where name=? ;");
preparedStatement.setString(1, "Sitansu");
preparedStatement.executeUpdate();
resultSet = preparedStatement.executeQuery("select * from login");
metaDateResultSet(resultSet);
} catch (Exception e) {
throw e;
} finally {
close();
}
}

private void metaDateResultSet(ResultSet resultSet) throws SQLException {
// Now get the metadata from thye database
System.out.println("The column in the table are....");
System.out.println("Table :" + resultSet.getMetaData().getTableName(1));
for (int i = 1; i <= resultSet.getMetaData().getColumnCount(); i++) {
System.out.println("column :" + i + " " + resultSet.getMetaData().getColumnClassName(i));

}
}

private void writeResultSet(ResultSet resultSet) throws SQLException {
// resultSet initialised before the first data set
while (resultSet.next()) {
// It is possible to get the columns via name
// also posssible to get the column via column no
// which starts at 1
// e.g., resultSet.getSTring(2);
System.out.println("User:" + resultSet.getString("name"));
System.out.println("password:" + resultSet.getString("password"));
}
}

// you need to close all three to make sure
private void close() {
try {
resultSet.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
statement.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
connection.close();
} catch (SQLException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}

package com.demo.mysqlaccess;

public class TestDataBase {

public static void main(String[] args) throws Exception{

// TODO Auto-generated method stub

MySqlAccess mySqlAccess = new MySqlAccess();

mySqlAccess.readDataBase();

}

}

Atomicity, Visibility and Ordering

Atomicity, Visibility and Ordering

(Note: I've cribbed this from my doctoral dissertation. I tried to edit it heavily to ease up on the mangled academic syntax required by thesis committees, but I may have missed some / badly edited in places. Let me know if there is something confusingly written or just plain confusing, and I'll try to untangle it.)

There are these three concepts, you see. And they are fundamental to correct concurrent programming. When a concurrent program is not correctly written, the errors tend to fall into one of the three categories: atomicity, visibility, or ordering.

Atomicity deals with which actions and sets of actions have indivisible effects. This is the aspect of concurrency most familiar to programmers: it is usually thought of in terms of mutual exclusion. Visibility determines when the effects of one thread can be seen by another. Ordering determines when actions in one thread can be seen to occur out of order with respect to another. Let's talk about them.

ATOMICITY

Everyone doing any serious concurrent programming knows what atomicity is (or will when I describe it) — I'm just putting it in for completeness's sake. If an action is (or a set of actions are) atomic, its result must be seen to happen ``all at once'', or indivisibly. Atomicity is the traditional bugbear of concurrent programming. Enforcing it usually means using locking to enforce mutual exclusion. To see atomicity in action (or in inaction, perhaps), consider this code:

class BrokenBankAccount {
  private int balance;

  synchronized int getBalance() {
    return balance;
  }

  synchronized void setBalance(int x) 
    throws IllegalStateException {
    balance = x;
    if (balance < 0) {
      throw new IllegalStateException("Negative Balance");
    }
  }

  void deposit(int x) {
    int b = getBalance();
    setBalance(b + x);
  }

  void withdraw(int x) {
    int b = getBalance();
    setBalance(b - x);
  }
}

Since all accesses to the shared variable balance are guarded by locks, this code is free of what are called data races, which are basically what happens when you access a variable concurrently without some use of synchronization or volatile or the like (one of those accesses has to be a write to be a data race in the true sense). When code is free from data races, we say it is correctly synchronized. So the code is correct, right?

No, of course not. This code is not at all correct, in the sense that it doesn't necessarily do what we want it to do. Think about what happens if one thread calls deposit(5) and another calls withdraw(5); there is an initial balance of 10. Ideally, at the end of these two calls, there would still be a balance of 10. However, consider what would happen if:

1. The deposit() method sees a value of 10 for the balance, then


2. The withdraw() method sees a value of 10 for the balance
   and withdraws 5, leaving a balance of 5, and finally


3. The deposit() method uses the balance it originally saw (10) to
   calculate a new balance of 15.

As a result of this lack of "atomicity", the balance is 15 instead of 10. This effect is often referred to as a lost update, because the withdrawal is lost. A programmer writing multi-threaded code must use synchronization carefully to avoid this sort of error. In Java, if the deposit() and withdraw() methods are declared synchronized, it will ensure that locks are held for their duration: the actions of those methods will be seen to take place atomically.

Atomicity, of course, is only guaranteed when all the threads use synchronization correctly. If someone comes along and decides to read the balance without acquiring a lock, it can end up with all sorts of confusing results.

Atomicity is the most common problem you get when using synchronization. It is a common mistake to think that it is the only problem; it is not. Here's another one:

VISIBILITY

What's visibility, you ask? Well, if an action in one thread is visible to another thread, then the result of that action can be observed by the second thread. In order to guarantee that the results of one action are observable to a second action, then you have to use some form of synchronization to make sure that the second thread sees what the first thread did.

(Note: when I say synchronization in this post, I don't actually mean locking. I mean anything that guarantees visibility or ordering in Java. This can include final and volatile fields, as well as class initialization and thread starts and joins and all sorts of other good stuff.)

Here's an example of a code with visibility problems:

class LoopMayNeverEnd { 
  boolean done = false; 

  void work() { 
    while (!done) { 
      // do work 
    } 
  } 
 
  void stopWork() { 
    done = true; 
  } 
} 

In this code, imagine that two threads are created; one thread calls work, and at some point, the other thread calls stopWork on the same object. Because there is no synchronization between the two, the thread in the loop may never see the update to done performed by the other thread. In practice, this may happen if the compiler detects that no writes are performed to done in the first thread; the compiler may decide that the program only has to read done once, transforming it into an infinite loop.

(By the way, "compiler" in this context doesn't mean javac — it actually means the JVM itself, which plays lots of games with your code to get it to run more quickly. In this case, if the compiler decides that you are reading a variable that you don't have to read, it can eliminate the read quite nicely. As described above.)

To ensure that this does not happen, you have to use a mechanism that provides synchronization between the two threads. In LoopMayNeverEnd, if you want to do this, you can declare done to be volatile. Conceptually, all actions on volatiles happen in a single order, where each read sees the last write in that order. In other words, the compiler can't prevent a read of a volatile from seeing a write performed by another thread.

There is a side issue here; some architectures and virtual machines may execute this program without providing a guarantee that the thread that executeswork will ever give up the CPU and allow other threads to execute. This would prevent the loop from ever terminating because of scheduling guarantees, not because of a lack of visibility guarantees. This is typically called cooperative multithreading. The only implementation I know that does this is the Oracle VM — check the box for details.

There's one more problem that crops up:

ORDERING

Ordering constraints describe what order things are seen to occur. You only get intuitive ordering constraints by synchronizing correctly. Here's an example of when ordering problems can bite you:

class BadlyOrdered {
  boolean a = false;
  boolean b = false;

  void threadOne() {
    a = true;
    b = true;
  }

  boolean threadTwo() {
    boolean r1 = b; // sees true
    boolean r2 = a; // sees false
    boolean r3 = a; // sees true
    return (r1 && !r2) && r3; // returns true
  }

}

Consider what happens if threadOne() gets invoked in one thread and threadTwo() gets invoked on the same object in another. Would it be possible forthreadTwo() to return the value true? If threadTwo() returns true, it means that the thread saw both updates by threadOne, but that it saw the change to b before the change to a.

Well, this code fragment does not use synchronization correctly, so surprising things can happen! It turns out that Java allows this result, contrary to what a programmer might have expected.

The assignments to a and b in threadOne() can be seen to be performed out of order. Compilers have a lot of freedom to reorder code in the absence of synchronization; they could either reorder the writes in threadOne or the reads in threadTwo freely.

How do you fix it? Synchronize your code carefully! In this case, you can throw a lock around threadOne or threadTwo, or you can declare them both to be volatile, and get the ordering you want.