On 14/02/2012 02:01, Richard Calmbach wrote:
Sorry to burst your bubble, but stateful knowledge sessions are most
definitely not thread-safe. I have seen hard evidence to this effect
in the form of incorrect execution results and log statements that
clearly show that two threads were interacting in unexpected ways. In
a nutshell: Rule consequences are not executed atomically. This can
cause unexpected working memory changes (e.g., fact insertion) to
happen on one thread in one rule consequence before another thread has
finished executing another rule consequence. Note that I'm not talking
about whatever threads Drools may be creating internally. I'm talking
about application threads.
I have found synchronizing on the session object to be a reliable
safeguard against unwanted thread interactions. Basically, this way
all external fact insertions and calls to fireAllRules() are serialized.
If this is not supposed to be necessary (synchronizing on the
session), then there is a thread-safety bug in Drools.
Over various releases we have tried to catch any areas that might bypass
these locks. If you have found one, please provide us with a unit test
and we'll fix.
Mark
-Richard
2012/2/10 Mark Proctor <mproc...@codehaus.org
<mailto:mproc...@codehaus.org>>
On 10/02/2012 03:36, Apache wrote:
Hey,
I am trying to get multiple threads to insert events and run rules against
the union of events inserted ( an as soon as they are inserted, a timer drools
thread kicking of fireallrules() is not an option because that would introduce
a delay ) and wanted some opinion on the following:
1. Stateless session is basically a wrapper around statefulsession and
since per doc statefulsession is not threadsafe is it safe to assume 2
threads cannot insert and run fireallrules to compare against a union of
objects inserted by multiple threads without some synchronication on event
insertion and ESP fireallrulesrules ? ( would the answer still hold despite a
drools-camel endpoint reading and storing exchanges from multiple threads ? )
stateful sessions are thread safe, they just aren't
multi-threaded. Each of the working memory actions hold a lock, so
only one thread at a time can enter.
2. If in the above point we simplify the case where the rule uses the
"from" keyword and reads from a cache or a Db ( is reading from
A cache supported out of the box ? ) then will drools bhaviour will be
bound by the thread which invokes fireallrules() ?
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
