Until now I did not need thread locals, but avoiding unused threads locals flying around in memory is welcomed improvement.
Quoting Justin Deoliveira <jdeol...@opengeo.org>: > 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 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ 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
