Hi, in GeoTools we have a number of thread locals used here and there for different purposes.
In general the reason to have a thread local boils down to the same two needs: - you have a non thread safe object that is expensive to create and that is used over and over in normal operation, meaning that, for example, a data access or a rendering operation will use it over and over, but in a way that does not make it easy to keep it around unless it's attached to the thread (think filter functions using number/date formatters, for example) - you actually need different threads to see a different set of values. This is what the env function does, it has a "local map" that provides a per thread enviroment (useful in web servers, where each thread is a different request) The main problem with thread locals is that they need to be cleaned up to avoid "normal" memory leaks and to guarantee the proper undeploy of web applications (a thread local wil prevent the webapp from being removed from the permanent generation causing a second kind of memory leak). So you need some lifecycle management, and in theory you'd need one for each thread local around. Which is definitely not feasible, atm we have thrad locals in referencing, in the env function, and in the postgis dialect, and I'd like to add one in the formatting functions as well. How is a web application going to be aware of all the thread locals around? So here is the idea: one thread local to rule them all. We could add this at the GeoTools class level: Object GeoTools.getThreadLocal(Class clazz); Object GeoTools.setThreadLocal(Class clazz, Object value); Object GeoTools.removeThreadLocal(Class clazz); void GeoTools.removeThreadLocals(); There would be only one thread local, which is a map keyed from the class that needs the thread local to the value, all managed by the GeoTools class. At this point all a web application needs to do is to add a servlet filter calling on removeThreadLocals() and the shared map would be removed from the thread. What do you think? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
