<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    One question that occurs to me is whether different Smalltalks
    exhibit different behaviors in switching from one process to another
    at the same priority. I recall thinking this was a bit odd when I
    first became aware of it and I seem to remember a discussion once
    about changing Squeak's behavior in this case. I don't know if other
    Smalltalks did change or were even different from the very
    beginning. If you run the following, do the three processes proceed
    at roughly the same pace or does 1 finish before 2 starts?<br>
    <br>
    <font face="Georgia">    | nums procs |<br>
          <br>
          nums := OrderedCollection new.<br>
          procs := (1 to: 3) collect: [ : i |<br>
              nums add: 0.<br>
              [<br>
                  10 timesRepeat: [<br>
                      [10000 factorial] timeToRun.<br>
                      nums at: i put: (nums at: i) + 1.<br>
                  ].<br>
              ].<br>
          ].<br>
          procs do: [ : e | e forkAt: Processor userBackgroundPriority].<br>
          nums inspect<br>
    </font><br>
    <br>
    <div class="moz-cite-prefix">On 3/10/15 7:51 AM, Sven Van
      Caekenberghe wrote:<br>
    </div>
    <blockquote cite="mid:D8988151-840A-43A8-A82F-B241EEA568AD@stfx.eu"
      type="cite">
      <pre wrap="">Well, we can't help him unless he give us a reproducible case.

My code shows there is no such problem.

There might be some miscommunication going on, but from my cursory reading, I got the impression that he suggests there is a fundamental problem with something except his own code.

</pre>
      <blockquote type="cite">
        <pre wrap="">On 10 Mar 2015, at 12:31, Nowak, Helge <a class="moz-txt-link-rfc2396E" href="mailto:HNowak@cincom.com">&lt;HNowak@cincom.com&gt;</a> wrote:

Hmm,

I am sure Ondrej understood what was proposed. He mentioned at least twice that the DB connections are NOT the problem. He said that the processing AFTER loading the data from the database into the image is the problem. Why shouldn't I believe him? OTOH I believe you Seaside experts that Seaside's architecture is inherently non-blocking between sessions.

Thus there are two questions:
- how could any processing block the whole Seaside image?
- how to find possibly problematic spots in Ondrej's application code?

Once that is resolved one could think about further improvements.

Cheers
Helge

-----Ursprüngliche Nachricht-----
Von: <a class="moz-txt-link-abbreviated" href="mailto:seaside-bounces@lists.squeakfoundation.org">seaside-bounces@lists.squeakfoundation.org</a> [<a class="moz-txt-link-freetext" href="mailto:seaside-bounces@lists.squeakfoundation.org">mailto:seaside-bounces@lists.squeakfoundation.org</a>] Im Auftrag von Sven Van Caekenberghe
Gesendet: Dienstag, 10. März 2015 12:12
An: Seaside - general discussion
Betreff: Re: [Seaside] Re: Concurrent requests from multiple sessions


</pre>
        <blockquote type="cite">
          <pre wrap="">On 10 Mar 2015, at 11:15, wilwarin <a class="moz-txt-link-rfc2396E" href="mailto:Ondrej.Altman@seznam.cz">&lt;Ondrej.Altman@seznam.cz&gt;</a> wrote:

( I tried Sven's code and it is possible to do another work during 
waiting, it is OK. )
</pre>
        </blockquote>
        <pre wrap="">
Does it also work (slowly) during the benchmark ?
That simulates your 'long running work'.

</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">But that problem (not being able to process concurrent requests) is 
certainly not inherent to Seaside or Pharo. If that were the case we 
should all stop using it.
</pre>
          </blockquote>
          <pre wrap="">
Hopefully I understand, so it is not the case. If I am correct, it 
means that in Seaside it is necessary to solve similar situations with 
different access. In case of for example difficult server-side 
calculation (or processing of big amount of data), we have to count on 
a possible problem with concurrent requests from multiple sessions. Am 
I right? Or, if not, where could the problem lay?
</pre>
        </blockquote>
        <pre wrap="">
What everybody here tries to explain to you is that the problem is most probably in your DB driver (in Smalltalk or further down): it probably cannot do more than one concurrent request (as it is currently implemented). That is not a Seaside nor a fundamental Smalltalk problem.

Try investigating that aspect, separate from Seaside._______________________________________________
seaside mailing list
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
_______________________________________________
seaside mailing list
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>
</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
seaside mailing list
<a class="moz-txt-link-abbreviated" href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</a>

</pre>
    </blockquote>
    <br>
  </body>
</html>