tags:

views:

145

answers:

1

I am fairly new to web development. So I apologize if this is a very basic question. For example, I create a web application and deploy it to tomcat. Now when multiple users hit the web application, does tomcat create a new thread per user? If that's the case then can I still create threads in my application itself and expect it to stay local to each user thread created by tomcat? Does session level data stay synchronized across threads?

I hope my question makes sense.

+8  A: 

each request is handled in a different thread. This is not a "thread per user". A request is any interaction from the client (web browser) and the server. So, typing a Url in you browser, invoking an ajax request, each one is handled in a separate thread.

The state a user acquires during a 'login' (it doesn't have to be a login per se; a better way to say it is "a set of related requests by one user") is conveniently stored in the session. You can use the session to store any data that is applicable to the user, although you should be careful not to store too much data because it eats up memory. Session management requires a degree of skill.

Yes you must be very careful if you fire off new threads; you can break things, and typically its a bad idea. If you must do something that will take a long time, use JMS to handle whatever it is asynchronously. Also remember that not all tasks that affect web application data have to invoked from the webapp. A task that scans the data daily can be run as a separate task in or out of tomcat -- i.e. you can write a job using something like quartz scheduler, or even write a separate program and set it up to run in a cron (be careful of the job changing the data from under you webapp, though).

If you are using best of breed technologies such as Spring and Hibernate, they typically bind objects (or can be configured by the app developer) that the programmer will need to each thread (using java's ThreadLocal).

This is also one of the reasons starting your own threads is dangerous. If you start your own thread, you might lose resources that are bound to the initial thread when the request ends, and this means that if you try to access those resources in your worker thread they wont be available. This type of bug can be a pain in the ass to find/fix.

edit - as Stephen C pointed out in a comment for another answer, its important to note that typically Tomcat (and other containers) maintain a pool of threads for use. This means that a new thread is not necessarily created for every request. It means that each request runs in a separate thread, which might or might not be created or reused.

hvgotcodes
Thanks for the detailed answer. How does someone do concurrent tasks in a web app then? Is it generally avoided even if you can get performance out of it?
What do you mean by concurrent? If a request starts a task that will take a long time, you need to handle is asynchronously. Using JMS is the answer here. The idea is you send a message to a queue or topic (and the initiating request ends), and a bean (message driven bean) is configured to watch the queue or topic and consume the messages on it, and do something time consuming based on the message. You'll need to google it to find out how to implement it, but its not difficult.
hvgotcodes
I appreciate it.
@user377067 no problem.
hvgotcodes