[rules-dev] StatefulKnowledgeSession: thread-safe

[Edson Tirelli]

    Wolfgang,

    That is correct. Drools has no control over the fact objects, as it
reuses whatever was provided by the application. If those objects are not
thread safe and the application is accessing them concurrently, a race
condition will happen.

   Edson

On Tue, Feb 14, 2012 at 2:26 AM, Wolfgang Laun <wolfgang.laun at gmail.com>wrote:

> (I don't want to confuse things by adding to the recent thread on the
> user list. And I do hope that I got this right. Please read carefully
> and correct me. Thanks.)
>
> The statement "StatefulKnowledgeSession is thread-safe" must be
> annotated with caveats so that users don't overload this basically
> simple statement with meaning that isn't logically implied by it.
>
> StatefulKnowledgeSession is thread-safe means that any two threads
> cannot interact in such a way that it would corrupt data protected by
> the implementing object. It does not mean that all code executed on
> behalf of the data maintained by a Stateful Knowledge Session object
> is thread-safe. In particular, the execution of a consequence is not a
> critical section from the session's point of view.
>
> The existence of an activation implies that the LHS conditions are
> true for the objects playing a part. As soon as one thread begins
> actions based on these preconditions and is on its way to modifying
> one or more facts, any other thread doing likewise with any of the
> participating objects in this or another RHS is running into a race
> condition.
>
> If a consequence execution is a critical section for some application
> object, it is the user's responsibility to achieve proper
> synchronisation, either for entire consequences or for individual fact
> objects.
>
> -W
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120214/e29bdc15/attachment.html