I think it sounds like a good idea. I know I use thread locals a lot and agree that it can be a pain to clean them up when you don't necessarily have a shutdown hook handy.
On 10-08-09 1:02 AM, Andrea Aime wrote: > 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 > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
