Can't you just rely on the cleanup() in FullTextIndexEventListener ? That would be a good place to use ThreadLocal.remove();
When using the "autoregistration" of the listeners (see EventListenerRegister), the ThreadLocal isn't used actually (As far as I understand): so as 3.1 does target core 3.3, is it still possible to use 3.1 with manual eventlistener registration? I guess i'ts possible, but should be useless: We could recommend against using the registration-by-configuration, and drop the TLocal in trunk. For safety the current name could change, and the new name could be removed/replaced during EventListenerRegister. To fix it for older hibernate (for Search 3.02 eventually), when autoregistration was not available, you could either use the cleanup() or exploit the order of registration: the last listener which is --usually-- registered has to clear the threalocal too. We should just verify if this registration order changed in hibernate's code during time. (The scenarios having FullTextIndexEventListener registered only to some events wouldn't be safe in this case, but I doubt they should be "supported" anyway..) just some ideas, I'm in no way a ThreadLocal expert. --Sanne 2008/12/1 Emmanuel Bernard <[EMAIL PROTECTED]>: > > On Nov 24, 2008, at 21:40, Hardy Ferentschik wrote: > >>> memory leak on redeploy (quite good information here, but this is >>> going to be hard) >>> http://forum.hibernate.org/viewtopic.php?p=2400319 >> >> A tricky one indeed. I don't think this is something we can address for >> the GA release. >> Interesting though. > > At first quick reading, this might be related to > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 > http://jroller.com/tackline/entry/working_around_the_threadlocal_leak > > need further investigation. > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
