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'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's own steam, right? But if the thread decides to use a new one, but the Factory keeps returning the thread's one and only instance, then it'll be very annoying. I guess the remaining active line private static ThreadLocal<Environment> environment = new ThreadLocal<Environment>(); and the //-commented shoudl be removed. As we have EnvironmentImpl now, it creates a simple HashMap, and this is passed on down into core'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's stored in the Environment. Perhaps: return the Environment in a synchronized Proxy? I'd be pleased to learn that I've overlookes something. Wolfgang