Looking at the code of org.drools.impl.EnvironmentFactory, I see some relics of an idea that the Environment should be Thread local. Now I can&#39;t imagine what good would come from this. If a thread calling newStatefulSession( null, x ) repeatedly wants to retain the Environment across repeated sessions, it can do so under it&#39;s own steam, right? But if the thread decides to use a new one, but the Factory keeps returning the thread&#39;s one and only instance, then it&#39;ll be very annoying. I guess the remaining active line<br>
    private static ThreadLocal&lt;Environment&gt; environment = new ThreadLocal&lt;Environment&gt;();<br>and the //-commented shoudl be removed.<br><br>As we have EnvironmentImpl now, it creates a simple HashMap, and this is passed on down into core&#39;s AbstractWorkingMemory. And getEnvironment() returns the reference from there to any calling thread; Environment.get() and Environment.put() permit arbitrary updates via this reference. I think that EnvironmentImpl objects or their HashMap need to be protected against race conditions. But wrapping the local HashMap into a ConcurrentHashMap punishes all the core accesses, with all the stuff (GLOBAL, etc.) that&#39;s stored in the Environment. Perhaps: return the Environment in a synchronized Proxy?<br>
<br>I&#39;d be pleased to learn that I&#39;ve overlookes something.<br>Wolfgang<br><br>