[rules-users] Multiple threading

[Mark Proctor]

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 <mproctor at codehaus.org 
> <mailto: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 list
>>     rules-users at lists.jboss.org  <mailto:rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://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/20120214/f3097db7/attachment.html