2013/3/16 Nick Williams <[email protected]>: > 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.
Java call chain belongs to a single thread. That is how the language works, regardless of connectors. As long as you clear it in the same place where you set it (a-la try/finally) you should not worry. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
