2015-04-14 2:28 GMT+03:00 Leo Donahue <donahu...@gmail.com>: > On Mon, Apr 13, 2015 at 5:25 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: >> >> 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 >> >> > The scenario I was proposing is more work than just implementing the > ServletRequestListener. > > One thread local variable was being created in each filter. > > In my previous scenario, I was going to remove thread locals in the web > service methods, but then realized I could remove them in the finally block > of the filters on the request's way back out the chain(s). > > I think I prefer the Listener approach better.
Filters are better. With Filter there is a guarantee that finally block is executed in the same thread. With RequestListener there is no guarantee that "requestDestroyed()" happens in the same thread. That method exists to perform cleanup of request attributes, not one of thread locals. https://bz.apache.org/bugzilla/show_bug.cgi?id=57314 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
