Hi,
The same thread may be used for the container to handle multiple
requests, though of course not concurrently. Any other behavior doesn't
scale so it doesn't make sense ;) I suggest you change your login
logic.
As for docs, what you're really looking for is source code, which is of
course
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
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
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
: 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
) based on the
product and the policy information. Each http session is related to an
eRights session.
Ross
-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:26 PM
To: Tomcat Users List
Subject: RE: Threads in Tomcat 5
hit send too soon
information. Each http session is related to an
eRights session.
Ross
-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 12:26 PM
To: Tomcat Users List
Subject: RE: Threads in Tomcat 5
hit send too soon. Another approach which I've used and is common
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
