Thread for doFilter and service - is it the same ?

K

Ken Carroll

Can anyone tell me if the doFilter method is called on the same thread
as the servlet's service method ?
 
S

Sudsy

Ken said:
Can anyone tell me if the doFilter method is called on the same thread
as the servlet's service method ?

I can't. But I have to ask a question in return: does it matter? I
would presume (but have no way of knowing without digging into the
source) that it wouldn't. A filter merely processes the request or
response. According to the javadocs it can choose to:
"4. a) Either invoke the next entity in the chain using the FilterChain
object (chain.doFilter()),
4. b) or not pass on the request/response pair to the next entity in the
filter chain to block the request processing"

There's no obligation on the part of the servlet container to run
filters in the same thread as the requested servlet. Obviously, if
a request filter opts to discontinue processing then the servlet
service method will never be invoked in the first place!
So why would you care?
 
K

Ken Carroll

Sudsy said:
I can't. But I have to ask a question in return: does it matter? I
would presume (but have no way of knowing without digging into the
source) that it wouldn't. A filter merely processes the request or
response. According to the javadocs it can choose to:
"4. a) Either invoke the next entity in the chain using the FilterChain
object (chain.doFilter()),
4. b) or not pass on the request/response pair to the next entity in the
filter chain to block the request processing"

There's no obligation on the part of the servlet container to run
filters in the same thread as the requested servlet. Obviously, if
a request filter opts to discontinue processing then the servlet
service method will never be invoked in the first place!
So why would you care?
If I have something plugged in as a filter which sets some logging
context for the thread servicing the request or does something with a
ThreadLocal on that thread. Currently this is done using a master
servlet which receives the request (service) and which then delegates
real request processing to a delegate (eg struts action servlet).

Ken
 
S

Sudsy

Ken Carroll wrote:
If I have something plugged in as a filter which sets some logging
context for the thread servicing the request or does something with a
ThreadLocal on that thread. Currently this is done using a master
servlet which receives the request (service) and which then delegates
real request processing to a delegate (eg struts action servlet).

Well I'm no expert, but wouldn't pragmatic design principles suggest
that the logging be initialized in the "master servlet"? I wouldn't
recommend the use of ThreadLocal in a server framework in any case.
Can't you achieve the same goal by storing a variable in the request
context? Just wondering out loud...
 
S

Sudsy

Ken Carroll wrote:
If I have something plugged in as a filter which sets some logging
context for the thread servicing the request or does something with a
ThreadLocal on that thread. Currently this is done using a master
servlet which receives the request (service) and which then delegates
real request processing to a delegate (eg struts action servlet).

I should really add something to my previous reply, since the OP
explicitly mentioned ThreadLocal. From the javadocs (always the best,
and should be the first, point of reference) for ThreadLocal:
"ThreadLocal instances are typically private static fields in classes
that wish to associate state with a thread (e.g., a user ID or
Transaction ID)."

Are you trying to specify a session-specific identifier? In which
case my previous advice is even more applicable: put the information
into the session context. I can still see no justification to create
a unique identifier for each individual request.
Perhaps you need to re-think your architecture? Just an idea...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top