Tomcat uses a ThreadPool so Threads are recycled. If you store something in a ThreadLocal it it your resposibility to clear the stored values at the end of the use. So if you store request variables you have to clear them at the end of the request (or before storing them at the beginning of the request).
Sadly the the ThreadLocal API has no means to clear the state for a thread easily. To clear it, you have to know what is stored in ThreadLocals. But as you describe your application that shouldn't cause a problem. > -----Original Message----- > From: Angelov, Rossen [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 6:27 PM > To: 'Tomcat Users List' > Subject: Threads in Tomcat 5 > > > Hi, > > I'm trying to understand how exactly Tomcat 5 is organized to > work with > threads. Is there any documentation on how the connector is using the > threads? What happens in the thread pool, how exactly the are > threads picked > from the pool and what is their state? And what happens with > the released > threads? > > Our login application is having problems when retrieving data from the > requests. I was debugging the process by printing out the > current thread > name and the request parameter values. > > Everything works fine when there is a different thread > assigned to each > request: > request 1 > current thread: http8080-Processor25 > request 2 > current thread: http8080-Processor23 > request 3 > current thread: http8080-Processor22 > > When an old thread is used for the new request, things don't > work (usually > the wrong parameter values are returned) and the debug output > looks like > this: > request 1 > current thread: http8080-Processor25 > request 2 > current thread: http8080-Processor23 > request 3 > current thread: http8080-Processor25 > > Our application uses ThreadLocal to create a Hashtable with > the current > request parameters as a cache storage. Very often the same > thread is used > for more than one requests, the parameter values are > retrieved from the > cache instead of using the new values. This completely breaks > the logic and > the login process fails. > > Thanks, > Ross > > > "This communication is intended solely for the addressee and is > confidential and not for third party unauthorized distribution." > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
