My colleague and I had a discussion about using multi-threading in an internet application. I think that the servlet container has its own thread pool to handle the requests. If using multi-threading, the container will get confused and will generate unprdictable results. Could anyone tell me whether I'm right or not.
P.S. if the admin thinks this question belongs to Thread forum, please feel free to help me move there.
Thank you for your reply and sorry I did not make it clear.
I mean I create a thread pool and maintain it myself. The threads will be used to do some stuff like calling a web service and doing some calculation. Is there a conflict between the thread pool maintained by Servlet Container and the thread pool I created. I just can not see how it works.
Originally posted by Ed Wallen: Servlets are by default multi-threaded unless you specifically implement javax.servlet.SingleThreadModel.
It is deprecated, long time ago.
Joined: Aug 15, 2004
Originally posted by Kevin Cui: I mean I create a thread pool and maintain it myself. The threads will be used to do some stuff like calling a web service and doing some calculation. Is there a conflict between the thread pool maintained by Servlet Container and the thread pool I created. I just can not see how it works.
Yes you can do that. But should be outside your servlet, otherwise all messed up. A servlet should just entertain your request and give response.
Joined: Mar 04, 2005
Thanks for your reply.
(1)If I have a class called ThreadsManager and all threads related activities such as creating threads, starting threads, and terminating threads are handled by this class. In my servlet, I call ThreadsManager.startManageThreads(). Can this consider as "outside the servlet"? If not, could you give me an example?
(2)Could you explain a little bit more on "other all messed up"?
Originally posted by Kevin Cui: (2)Could you explain a little bit more on "other all messed up"?
Consider a situation where (for some reason) you give multiple threads access to the output stream and get them to write to the client. Without some management the client is going to get strange results. Some would call it garbage.
This sounds unreasonable, but you can create this situation when attempting to include JSPs from another context. Depending on the vendor, the request may re-enter through the thread pool, get assigned a different thread, and you have no control over where the included content actually gets placed. This is also one of my favourite examples for talking people out of trying to be clever with cross-context responsibilities