Just imagine that you use your RequestDispatcher to include a servlet (for a forward this is not so clear). You have some variables, some kind of state that you want to find again when you come back from the include call.
But a servlet instance is part of a thread, and only one thread access a servlet at once. So if a dispatch is made in another thread, the coming back could come in another thread, which means you could loose your previous state.
For this (and other reasons probably), a dispatch should be made in the same thread.
hi fedric, thanks for ur reply.. But i have a question ,since for each request container forks a thread from a servlet instance(not taking SingleThread Model into cosideration) which serves the request .But how can a request meant for thread (Lets say A) be dispatched from another thread (B)
I mean if i have to diapcatch(include) a request from A->C then how it is possible to do same(for the same request) from B->C unless u do somthing like A->B then B->C.
from a servlet instance(...) which serves the request .But how can a request meant for thread (Lets say A) be dispatched from another thread (B)
It is not dispatched to other threads, that's the point.
Your container creates a ServletRequest instance when it receives an HTTP request from outside, then forks a new thread (or picks one from a pool or whatever) and then runs the service(...) of the Servlet instance with this ServletRequest instance (and ServletResponse) using the thread it just picked. Then, if you never fork the thread yourself, the container guaranties than whenever you forward/include the request, all the processing will happen in the same thread, that is, sequencially : you never have the servlet where you forwarded/included your request run in parallel of you current request.
It is a mistake to think you can solve any major problems just with potatoes.<br />--Douglas Adams