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