• Post Reply Bookmark Topic Watch Topic
  • New Topic

thread id for a request across multiple components

 
Arvind Rasengan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, I didn't know how to search if this question/scenario has been discussed already. Please help me out.

I have a simple test application which is structured as follows: The user accesses a jsp page from a browser (where I print Thread.currentThread().getId()..as say, JSP_Id). The JSP page has a submit button which the user clicks to forward the request to a servlet where I print the current thread id again as say Servlet_Id. The Servlet calls a DAO class and does JDBC stuff where I print the current thread Id again as say, DAO_Id and the servlet forwards the request to another JSP page where I print the current thread id again as say JSP_last_Id.
I don't know much about java/JVM/OS internals but I find that all the thread Ids I have printed above are all the same for a request and usually for subsequent requests also! I thought that each component/process (Jsp, servlet, DAO) would have a separate thread Id but thats not the case. When a request gets completed, I can understand that the threads are freed and are reassigned to subsequent requests which might explain the 'same thread id across multiple requests' thing.

In any case, how would I use this thread id concept to track a single requests life cycle in the web application? Thank you very much for any light on this!
 
Zhui Shen Ge
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about a ThreadLocal object to store more specific information (e.g. sessionId, userId)?
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mega Lodon wrote:I thought that each component/process (Jsp, servlet, DAO) would have a separate thread Id but thats not the case.


Unless and until you make provisions to change the thread (using a threadpool or what we call as a queuing point), the thread will be the same.

Mega Lodon wrote:
In any case, how would I use this thread id concept to track a single requests life cycle in the web application? Thank you very much for any light on this!


As Zhui pointed out you can use ThreadLocals but that gets a little tricky when the threads get re-used because you need to clear and re-populate the state at correct points otherwise it may create more problems than solve.

What is the intention of tracking the request lifecycle?
 
Arvind Rasengan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Zhui and Nitesh,

Thank you very much for the clarifications. I always thought that each component would be in its own process and would hence get some random, unequal thread id. Threadlocal does sound intriguing but I will also take into account Nitesh's warning.
I am mainly trying to track requests to a few web applications to identify bottlenecks in them.
Thanks
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mega Lodon wrote:
I am mainly trying to track requests to a few web applications to identify bottlenecks in them.
Thanks


For performance evaluations, it is best to use a profiler than to change code to gather statistics.
 
Arvind Rasengan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the advice Nitesh...but I am not changing any code going forth. It is all external.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arvind Rasengan wrote:Thanks for the advice Nitesh...but I am not changing any code going forth. It is all external.


Well doesn't matter, code is a code, internal or external. You can easily profile with a profiler, if that is the only goal.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!