[rules-dev] Session, Environment and threa[dt]s

Wolfgang Laun wolfgang.laun at gmail.com
Fri Nov 26 04:34:00 EST 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101126/5e8ab2f2/attachment-0001.html 


More information about the rules-dev mailing list