On Nov 24, 2008, at 11:17, Sanne Grinovero wrote: The implementation suffers several flows: - we do create an EntityInfo[] as big as the number of hits - we lazily load this array but we never release "old content" - we lazily load the content (ie objects) by window but we never release it Some Soft reference based cache can help.

Hi, it was quiet whole day and then you go a couple of hours and look what happens ;-) On Mon, 24 Nov 2008 17:17:58 +0100, Sanne Grinovero <sanne.grinovero(a)gmail.com&gt; wrote: Sounds odd to me as well. I will follow up on this tomorrow. I doubt though that just using Spring makes a difference. A tricky one indeed. I don't think this is something we can address for the GA release. Interesting though. I agree with Emmanueel. We should the improve on the underlying implementation. This issue might be important enough to fix for GA. --Hardy

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 <emmanuel(a)hibernate.org&gt;: