-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Leo,
[re: Removing ThreadLocal variables]
Uh, oh.
On 4/13/15 10:50 AM, Leo Donahue wrote:
> Tomcat 7.0.61 Java 1.7.0_75
>
> Scenario:
>
> Class1 static Type ThreadLocal variable static Type
> getThreadLocal(){...} static Type setThreadLocal(){...} static void
> destroy(){variable.remove}
>
> Class2 static Type ThreadLocal variable static Type
> getThreadLocal(){...} static Type setThreadLocal(){...} static void
> destroy(){variable.remove}
>
> user makes a request to a stateless jax-ws web service request hits
> filter1 filter1 - Class1.setThreadLocal filter1 - calls
> chain.doFilter() filter2 - calls methods on Class1 filter2 -
> Class2.setThreadLocal filter2 - calls chain.doFilter() web service
> method processes request
>
> Removing the thread local:
>
> web service method calls Class1.destroy() and Class2.destroy() (and
> it does this for all exception cases within said web service
> method)
>
> Is this an acceptable pattern or is it better to implement a
> ServletRequestListener to remove thread local variables?
The good news is that you are thinking about this in the correct way:
that requests are handled by (usually) one thread and you have to
clean the ThreadLocal in the correct thread, otherwise Bad Things can
happen.
Unfortunately, the one-thread-per-request scheme only works for
certain types of requests. If you are using WebSocket, Comet, etc.
then that can fall apart on you.
Back to your use-case. A ServletRequestListener itself isn't
absolutely required, but it probably makes the most sense
architecturally: the infrastructure is already there for you, and the
behavior is orthogonal to the actual work you are trying to accomplish.
It's not clear to me exactly what you are proposing above, but if it
matches the semantics of the ServletRequestListener, then it sounds
okay to me.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVLEJQAAoJEBzwKT+lPKRYwuUQAJZgavnvbBWOHxsQFluaEUV9
awPUKexfftoqL3hrCC80pUiMGqmrVtWFkMTLTFplvJoVn6dzfyp3Go248sjGN/Vz
miGpFFTVmvaETXlJrDw07PvPVcvL/ft10YLAXIQ/UJLXJmsrn+UESALA8fsg7TBK
l/tgmic0e+fI6rPqtd014ghu81rtMr0rQnKCzkSk61jM3O01h62DMKlYyaVus6MG
7w3WDXNSBYpdqOFgu8uqQJPw8ZcRminULm1UrX+4S8zzL5/yQprTzUsN+1dQjQeF
dkQUiiAGFhUPdZRVJJOSEM8LKw3y0TiqEzy5WjXFIdA9kuOEMzNmpJIS+sKM/rDE
mhbtKGDYIeTXHA8jKXrE2FCWa/belPzOn6MM7syTQfRDuncnStJXjweSPd0eBW7L
cBko6+gpvEQ/ksl7hq5NyAubXIk3QYwUTmmud5hP8Mr97ZQmJS+7bOuNtb45Rjbm
FGajhx1uMrGfSuErjXg9irQDyITGZaBrCMncd0IQHBNG5FO1GF0UxAWd00O3Ed0M
ZkzPcl/x6jUNkMD4DDpP5K5+db25mPp/7aSNuw0tzOy0mFm+zLGpEQUhc20dpFvn
BAFTzgZ8d5YF/MjtYUAKDS/Ohy0MPI6ijCYcdYLvrdCxS3+Azm/esPAfbuYpVVGa
fV0Io+r296bnZgkBuJ3H
=PaYO
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
