hit send too soon. Another approach which I've used and is common is to have the notion of access control privledge like Unix file privledges. Each page has a set privledge level and once the user is authenticated, the page checks the users access level. there are numerous other variations on this for single-sign-on applications. peter
"Angelov, Rossen" <[EMAIL PROTECTED]> wrote: Well, the login requirements are not that simple to explain in few lines. Some pages require authentication some don't, so it won't be appropriate to do this when the HttpSession is first started. ThreadLocal is used to identify the current thread (assuming that's for the current request) to get the request parameters and create a hashtable for caching purpose (this was done to speed up the registration process where over 30 demographic fields are passed between pages). The same logic is used when logging in or uploading a file with MultipartRequest. The applications were originally created 2-3 years ago to work on iPlanet and now I'm trying move them to Tomcat but it looks like there will be lot of problems. Ross -----Original Message----- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 11:21 AM To: Tomcat Users List Subject: Re: Threads in Tomcat 5 why do you want to use a thread to manage authentication? given the requestProcessor threads are reused, it makes no sense to use the thread for the mapping. you're better off just authenticating the first time and setting the HttpSession, rather than look up the thread. I'm probably missing something. peter "Angelov, Rossen" wrote: 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." --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today "This communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution." --------------------------------- Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway - Enter today
