[rules-users] Multiple threading

Richard Calmbach rcalmbac at gmail.com
Mon Feb 13 21:01:53 EST 2012


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.

-Richard

2012/2/10 Mark Proctor <mproctor at 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 listrules-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120213/0d0673cb/attachment.html 


More information about the rules-users mailing list