Almost a year ago we discussed the use of ThreadLocals and why to avoid them, nicely summarized at the time by Bram. This week I stumbled upon two articles that support our conclusion and are probably therefore worth sharing here:
The first is about why ThreadLocals break down when using the more scalable form of IO processing in Java called NIO (New IO): http://www.murkycloud.com/2011/10/thread-local-and-why-you-should-know.html The second, by Uncle Bob, approaches this more from a design point of view: http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-abomination Greetings, Marcel On Jan 18, 2011, at 17:54 , Bram de Kruijff wrote: > 4) On the context discussion > > As seen on the mailing list and in JIRA. Mainly discussed wether a > threadlocal based strategy for providing omnipresent pluggable context > information to services is desireable, doable and what the > alternatives are. Conclusion is that it is not our principle mechanism > (tenant aware services are) and it has too many drawbacks (no way to > deal with async) and/or open questions to promote to an official > mechanism. However it may (and probably must) be used in some cases to > workaround 3rd party software design limitations (eg. Shindig using > Guice injection). It shall however remain an implementation detaiil > and responsibility to those modules.
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
