I know, I know. "Don't use ThreadLocals." I've seen it on this list at least 100 times. But avoiding ThreadLocal variables can be hard:
1) Spring Framework uses ThreadLocals for things like the RequestContext. You can't just turn that off. 2) Spring Security uses ThreadLocals for things like the security context. Can't turn that off, either. 3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't always useable replacements for ThreadLocal variables. Doing this couples all aspects of your application to ServletRequests and/or HttpSessions. For example, in a multi-tenant environment, you need to establish some context that identifies which persistence location to use for obtaining and persisting data. Having to pass a request or session from servlet to service to repository is not ideal. Neither, for that matter, is having to have a "tenant" parameter (or any other type of identifying parameter) added to every single method in the entire application. And, when you're dealing with existing interfaces (Spring, Hibernate) that you have to implement, this isn't even an option sometimes. So, with that in mind, the logical question is, how does one use ThreadLocals safely and reliably? The obvious first step is, "don't let them leak." That's easily solved. We have a filter that performs the setting of all of our ThreadLocals on the way in, and it also clears them on the way back out. The ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where they were still leaking, and we fixed those, too. But, reading about the differences between BIO/NIO/APR, I'm concerned that may not be enough. If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen? I don't really understand how any of this works, so some advice is greatly appreciated. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
