<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 14/02/2012 02:01, Richard Calmbach wrote:
    <blockquote
cite="mid:CAGG6ETAC6QHBs+WEe44cwDha=3FYcovZxApn0quhvPg=RkCtJQ@mail.gmail.com"
      type="cite">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.
      <div>
        <br>
      </div>
      <div>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.
        <div>
          <br>
        </div>
        <div>If this is not supposed to be necessary (synchronizing on
          the session), then there is a thread-safety bug in Drools.</div>
      </div>
    </blockquote>
    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.<br>
    <br>
    Mark<br>
    <blockquote
cite="mid:CAGG6ETAC6QHBs+WEe44cwDha=3FYcovZxApn0quhvPg=RkCtJQ@mail.gmail.com"
      type="cite">
      <div>
        <div><br>
        </div>
        <div>-Richard<br>
          <br>
          <div class="gmail_quote">2012/2/10 Mark Proctor <span
              dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>&gt;</span><br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div class="im"> On 10/02/2012 03:36, Apache wrote:
                  <blockquote type="cite">
                    <pre>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 ? )</pre>
                  </blockquote>
                </div>
                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.<br>
                <blockquote type="cite">
                  <div class="im">
                    <pre>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() ? 
</pre>
                    <br>
                    <fieldset></fieldset>
                    <br>
                  </div>
                  <div class="im">
                    <pre>_______________________________________________
rules-users mailing list
<a moz-do-not-send="true" href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
                  </div>
                </blockquote>
                <br>
              </div>
              <br>
              _______________________________________________<br>
              rules-users mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
              <a moz-do-not-send="true"
                href="https://lists.jboss.org/mailman/listinfo/rules-users"
                target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
              <br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>