This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
4. When we say request/response, is each req/res a thread?
This says that you did not understand the principles of threading.
If you code a program, imagine the flow as a single lane highway.
Now, creating threads means creating more lanes on the highway.
This is called concurrency and it brings a lot of things to watch out for (thread safety).
to 1: A servlet is not single threaded. To increase the throughput of request a Servlet is multithreaded. To keep the memory footprint down the same servlet instance is used among multiple threads. It is important to understand this as you otherwise could walk into serious trouble when you don't watch out for thread safety.
to 2. Sessions are not thread-safe. There is one session instance per client but even a client could accidentally or purposely fire requests concurrently.
JDBCSupport - An easy to use, light-weight JDBC framework -
Web Server is like a factory.
Thread is like a worker in the factory.
Request/response is like an order from our client for the task to be done.
Servlet is like a recipe for carrying out particular order.
Session is like a noteboook where we store notes about one client.
If there is only one work (request) to be executed at given time, then only one worker (thread) is neccesarry, the others could have coffe-break.
The worker (thread) take the recipe (servlet), if needed - look at the notebook for this client (Session object) , and execute the order (request).
But if we get three request (orders) at the same time, then we have to call three workers from the coffe bar.
Workers take recipes (servlets), execute orders, then go to the bar for lunch.
If we get three orders of the same type (3 requests to the same servlet), then 3 workers take the same recipe (servlet)
and execute tasks. But in this recipe (servlet) there are several tools (resources) that can be used only by one worker at the same time,
so access to these tools (resources) has to be synchronized (one worker has to wait until the other worker finishes his job using this tool).
If we have only 3 workers (threads) in our facory and get 10 orders (request), then we can execute only 3 orders, the others have to wait.
Suma Rangaraj wrote:
1. How does a servlet execute?
When a request comes into a Servlet Container, it finds a Thread (either a new one, or one that is already created but not doing anything) and uses it to start executing the code inside the appropriate Servlet.
It's single threaded right?
No. You should consider every Servlet to be running in a multi-threaded environment. At the very least, if there is more than one request to the Server then there will generally be more than one Thread running. Also generally speaking there will only be one instance of the Servlet loaded, which means all the threads share the same instance and instance variables, which makes using Servlets with instance variables not a safe thing to do. Prefer to use only method local variables and pass those variables from one method to another using parameters.
What dos it mean when we say single threaded? Does that mean it is thread safe?
No. When we say 'single threaded' we are talking about an application whose logic is run all in one, single thread. When the application logic is run in more than one Thread it is multi-threaded. If your application runs in a single thread you don't really have to worry about thread safety. If your application runs in multiple threads then you definitely do have to worry about thread safety. As said previously, the Servlet should always be considered to run in a multiple threaded application and so you have to worry about thread safety.
2. if there are more than one session how do I understand it in terms of threads.
This has already been addressed. Sessions like everything else in the servlet environment can be accessed in multiple threads at the same time and are are not thread safe. You should consider thread safety implications when storing and retrieving from a session.
3. In the above URL, he says buffers are not shard between threads.I mean why would you want to share it in the first place?
I think the writer of that blog post slightly over-stated the 'never shared between threads' concern. StringBuffers are generally used to accumulate output that is taken in chunks and then turned into a String. Using the StringBuffer is more efficient than using Strings for this because Strings can't be changed, so you end up creating a lot of intermediary Objects to get the results you want. Since StringBuffers are used to accumulate output you can imagine times when you may have a complex task which is shared over a couple Threads all wanting to accumulate a report to the same location. You would then share the same StringBuffer between threads. It is possible to do this in a web application, and I have seen/done this myself - but only when working with Threads I have created and manage myself for processing a single request, never sharing the same buffer between requests. It is rare though. Generally in the context of a web application you would run all the code for a single request in a single thread so any StringBuffers you use would be maintained only in a single thread and would not need to be synchronized.
4. When we say request/response, is each req/res a thread?
Yes, each request is run in a Thread, and multiple simultaneous requests will run in different Threads. But Threads can be re-used as well. For example.
Request1 Starts -> Runs in Thread1
Request2 Starts -> Runs in Thread2
Request3 Starts -> Runs in Thread3
Request4 Starts -> Runs in Thread2
5. What is a thread in a web application??
The same as a thread in any other application. You should probably read this Tutorial to get a better idea of what Threads are and how they work.