57

Can someone please explain what is thread per request and thread per connection? Which model do servlets work on? How threads are allocated to handle HTTP requests? Is it thread/request or connection?

And let's say if I want to perform a time consuming task in my Servlet's doGet() method asynchronously, I start a new thread using Java executors so that lengthy calculations are done in a separate thread and response is sent right away.

Now does that ensure that I have freed the thread which had been processing my HttpServletRequest or is it still being used because a child thread is still running?

tmarwen
  • 15,750
  • 5
  • 43
  • 62
hellojava
  • 4,904
  • 9
  • 30
  • 38

1 Answers1

61

Per request means when an HTTP request is made, a thread is created or retrieved from a pool to serve it. One thread serves the whole request. Thread per connection would be the same thing except the thread is used for an entire connection, which could be multiple requests and could also have a lot of dead time in between requests. Servlet containers are thread per request. There may be some implementations that offer thread per connection, but I don't know, and it seems like it would be very wasteful.

Creating a thread inside another thread doesn't establish any special relationship, and the whole point of doing so in most cases is to let the one thread do more work or terminate while the other thread continues working. In your scenario, using a different thread to do work required by a request will, as you expect, allow the response to be sent immediately. The thread used to serve that request will also be immediately available for another request, regardless of how long your other thread takes to complete. This is pretty much the way of doing asynchronous work in a thread-per-request servlet container.

Caveat: If you're in a full Java EE container, threads may be managed for you in a way that makes it a bad idea to spawn your own. In that case, you're better off asking the container for a thread, but the general principles are the same.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • 1
    This is not how you should do asynchronous work in a container, it may be the simplest but it is not recommended. http://stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged/533847#533847 – Robin Sep 18 '11 at 00:15
  • @Robin: Good call. I added a caveat about full JEE containers. I usually think in terms of simple servlet containers. – Ryan Stewart Sep 18 '11 at 01:03
  • @Robin: Thanks guys. I am not handling the thread life cycle by myself. I plan to use Spring TaskExecutor abstraction.http://static.springsource.org/spring/docs/2.0.x/reference/scheduling.html#scheduling-task-executor-usage My web app is working under tomcat 6. Spring also provide workmanager implementation as mentioned in the link but it says its not JEE specification. Which one is better in my enviornment? – hellojava Sep 18 '11 at 07:37
  • In Tomcat, I'd say whichever one you're more comfortable with. Also, you should use the [latest Spring reference](http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/scheduling.html) unless you're really using Spring 2.0. – Ryan Stewart Sep 19 '11 at 04:10
  • @RyanStewart can u tell me that how servlet will maintain thread i mean multiple thread means if i have done 300 request then what about 300th thread? when it will execute? – Kishan Bheemajiyani Oct 14 '14 at 09:13
  • I have a doubt regarding "In your scenario, using a different thread to do work required by a request will, as you expect, allow the response to be sent immediately.". How could I send the response immediately without knowing what is the final response? It is like if I order a chef a dish, he comes back immediately without any proper response about my order and stands mum. :) – randomcompiler Jun 10 '15 at 20:33
  • @abhishek08aug It's useful when you publish some long running job. That kind of endpoint will create a job, return immediately some it's ID, and there should be another endpoint for checking the job status/result. – Jakub Malec Aug 18 '17 at 10:48
  • @RyanStewart This is probably the best answer to clear doubt about the famous thread per servlet question in Java – Gaurav Jul 06 '18 at 13:15