If your servlets only read from the request,
If your servlets only read from the request, write to the response, and save information in local variables (that is, variables declared within a method), you needn’t worry about the interaction among these threads. Once any information is saved in nonlocal variables (that is, variables declared within a class but outside any specific method), however, you must be aware that each of these client threads has the ability to manipulate a servlet’s nonlocal variables. Without precautions, this may result in data corruption and inconsistencies. For example, the SimpleCounterservlet makes a false assumption that the counter incrementation and output occur atomically (immediately after one another, uninterrupted). It’s possible that if two requests are made to SimpleCounteraround the same time, each will print the same value for count. How? Imagine that one thread increments the count and just afterward, before the first thread prints the count, the second thread also increments the count. Each thread will print the same count value, after effectively increasing its value by 2.* The order of execution goes something like this count++ // Thread 1 count++ // Thread 2 out.println // Thread 1 out.println // Thread 2 Now, in this case, the inconsistency is obviously not a problem, but many other servlets have more serious opportunities for errors. To prevent these types of problems and the inconsistencies that come with them, we can add one or more synchronized blocks to the code. Anything inside a synchronized block or a synchronized method is guaranteed not to be executed concurrently by another thread. Before any thread begins to execute synchronized code, it must obtain a monitor (lock) on a specified class. If another thread already has that monitor because it is already executing the same synchronized block or some other block with the same monitor the first thread must wait. All this is handled by the language itself, so it’s very easy to use. Synchronization, however, should be used only when necessary. On some platforms, it requires a fair amount of overhead to obtain the monitor each time a synchronized block is entered. More importantly, during the time one thread is executing synchronized code, the other threads may be blocked waiting for the monitor to be released. * Odd factoid: if count were a 64-bit long instead of a 32-bit int, it would be theoretically possible for the increment to be only half performed at the time it is interrupted by another thread. This is because Java uses a 32-bit wide stack. For SimpleCounter, we have four options to deal with this potential problem. First, we could add the keyword synchronizedto the doGet()signature: public synchronized void doGet (HttpServletRequest req, HttpServletResponse res) This guarantees consistency by synchronizing the entire method, using the servlet class as the monitor. In general, though, this is not the right approach because it means the servlet can handle only one GET request at a time. Our second option is to synchronize just the two lines we want to execute atomically: PrintWriter out = res.getWriter(); synchronized (this) { count++; out.println (”Since loading, this servlet has been accessed” + count + ” times.”); } This approach works better because it limits the amount of time this servlet spends in its synchronized block, while accomplishing the same goal of a consistent count. Of course, for this simple example, it isn’t much different than the first option.
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services